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(a)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.
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