On 18.10.19 17:21, Robbie Harwood wrote: > While you're right that the solutions from source distros (i.e., NixOS > and Gentoo) would be very hard to adapt, binary distros have also solved > this problem in different ways. I'm most familiar with Debian's > solution (virtual packages[2], provides:, and alternatives [1]) which > to my mind maps much more clearly onto Fedora's setup. Obviously we > can't use their code wholesale without migrating to APT, but as you say, > the goal is to derive inspiration. > > Thanks, > --Robbie > > 1: https://wiki.debian.org/DebianAlternatives > 2: https://www.debian.org/doc/debian-policy/ch-relationships.html#s-virtual I'm not a Fedora packager (yet[1]), so correct me if I'm misunderstanding things completely, but is there any reason not to adapt the existing RPM provides: functionality for this? That is essentially what Archlinux does with their pacman, where an second version of the same program will typically both Provide: and Conflict: with the 'default' package. It's extensively used by users to provide e.g. development versions of stable packages, see e.g. inkscape-git [2]. - if you install inkscape, you get the default version - if you install inkscape-git, you get the development version - when resolving dependencies, pacman knows that inkscape-git provides the capabilities of (Provides:) but cannot be installed together with (Conflicts:) of the package named inkscape - otherwise, they are two separate packages, so you don't have the problem of implicitly switching streams Parallel installability is taken care of with compat packages as usual, though if the packages happen to be parallel installable, there's probably no reason not to allow that via 'provides:' without 'conflicts:' What I like about this approach that all this magic only comes into play when resolving dependencies. In all other circumstances they are packages like any other, and are treated as such. Christopher [1] https://bugzilla.redhat.com/show_bug.cgi?id=1756582 [2] https://aur.archlinux.org/packages/inkscape-git _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
