On Fri, Oct 18, 2019 at 02:00:11PM -0700, Adam Williamson wrote: > On Fri, 2019-10-18 at 16:25 -0400, Robbie Harwood wrote: > > Christopher Engelhard <ce@xxxxxxx> 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. > > I don't think there is one. But it's not a perfect solution either. > Modularity is intended to do that - to provide a framework and some > technical backing for treating alternate groups of packages that > provide different implementations of the same thing *as* groups, > essentially. > > I mean, it's not like the Modularity team wasn't aware of these other > approaches, I'm pretty sure they were discussed. It might be reasonable > to go back and check the various docs and blog posts and things the > modularity team put out before just suggesting 'hey what about this > other thing', especially where 'this other thing' is something you > could reasonably imagine at least one of them would probably have heard > or thought of... Well, you might think that, but it's not clear that this was the case. Let's not assume one way or the other. > I mean, we're talking about *stacks* here, remember. FreeIPA isn't one > package - you can't just have 'freeipa4' and 'freeipa5' both providing > 'freeipa' and call it a day. There's a whole ton of stuff that goes in > there. 'freeipa5' might need different version of ten different other > components compared to 'freeipa4'. > > So, you're no longer looking at one pair of packages with the same > 'provides', you're looking at a dozen, and someone needs to be keeping > track of which ones go together and what they're all for in the first > place. But with this approach you're not building any infrastructure > for *doing* that. I would really like this explained. Taking this particular example, to let dnf install all dependencies properly, freeipa5 must already list *all* dependencies through rpm Requires/Conflicts/Recommends/Suggests, including versions. Likewise, freeipa4 must also do that. It doesn't matter if the rpms are built normally or in a module, listing all deps is needed in both cases. If the rpm doesn't work with all versions of dependencies, it might be fine during initial installation, where you get everything latest by default, but will break if the user does a partial upgrade. This means that in one case the user says 'dnf install freeipa5' and they get the full stack, and in the other case they say 'dnf install freeipa4' and they get a different (partially overlapping) set of recursive deps. > These things are clearly a conceptual lump, but > you're not really providing a way to express or work with that. Why not? What is wrong with having rpm Requires? Zbyszek _______________________________________________ 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
