Changes between Initial Version and Version 1 of Ticket #16336, comment 13
- Timestamp:
- Sep 25, 2024, 6:07:09 PM (2 weeks ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
Ticket #16336, comment 13
initial v1 1 In my earlier comment I described how we could get Virtual Packages using conflicting variants. The idea is, to spell it out, that the dependent port depends on the virtual port, and that virtual port can be installed using one of several ways, depending on how you specify (mutually exclusive) variants. The variants drive setup a dependency the the implementing port. I think ORed dependencies and Virtual Packages are alternative solutions to the same problem. Virtual Packages have the advantage of hiding "Implementation" (the actual package) behind and "Interface" (virtual package). At least Debian uses this approach as well [1], but I think others as well.1 In my earlier comment I described how we could get Virtual Packages using conflicting variants. The idea is, to spell it out, that the dependent port depends on the virtual port, and that virtual port can be installed using one of several ways, depending on how you specify (mutually exclusive) variants. The variants drive setup a dependency the the implementing port. I think ORed dependencies and Virtual Packages are alternative solutions to the same problem. Virtual Packages have the advantage of hiding "Implementation" (the actual package) behind and "Interface" (virtual package). At least Debian uses this approach as well ![1], but I think others as well. 2 2 3 I'm not sure which approach will be better in the long run. And we should probably have only one, not both. But I have tried to implement this as a port group and I find the result quite reasonable, because it does not require changes to the core workings, i.e., not very intrusive, and the resulting "virtual" portfile is short [2], here the postgresql example. And you can list virtual packages, if we put them all into a category "virtual", which is what my patch does. So now we have both options really open for discussion. One disadvantage is that it is very explicit, resulting in portfiles proper, instead of just symbols or names. Which have to be kept current and all. Just have a look. Patch follows.3 I'm not sure which approach will be better in the long run. And we should probably have only one, not both. But I have tried to implement this as a port group and I find the result quite reasonable, because it does not require changes to the core workings, i.e., not very intrusive, and the resulting "virtual" portfile is short ![2], here the postgresql example. And you can list virtual packages, if we put them all into a category "virtual", which is what my patch does. So now we have both options really open for discussion. One disadvantage is that it is very explicit, resulting in portfiles proper, instead of just symbols or names. Which have to be kept current and all. Just have a look. Patch follows. 4 4 5 [1] http://www.debian.org/doc/FAQ/ch-pkg_basics.en.html#s-virtual5 ![1] http://www.debian.org/doc/FAQ/ch-pkg_basics.en.html#s-virtual 6 6 7 [2] http://pastie.org/2572397 ![2] http://pastie.org/257239