Christopher Engelhard <c...@lcts.de> writes: > 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. >> >> 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?
I'm not aware of technical reasons not to do this - as Neal elaborated on, this is already possible. > 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. Yup! Thanks, --Robbie
signature.asc
Description: PGP signature
_______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
