On Wed, 2022-11-23 at 08:47 -0500, Michael Orlitzky wrote:
> On Wed, 2022-11-23 at 08:38 +0100, Michał Górny wrote:
> > Hello, everyone.
> >
> > TL;DR: I'd like to add sys-meta/{cpio,sh,tar} to install and control
> > (via USE flags) /bin/{cpio,sh,tar} symlinks.
> >
> > Draft PR: https://github.com/gentoo/gentoo/pull/28390
> >
>
> I generally favor using the package manager in these situations, but
> there's a lot of user-facing documentation (and user configurations)
> that will need updating. We should probably have a GLEP -- and
> eventually a news item -- for this.
>
> A few comments:
>
> * The new category is a bit annoying. I know the PMS says that
> virtuals can't install files, but having an entirely separate
> category for virtuals that install a symlink feels excessive.
> Not that I have a better idea.
Do you have any specific concerns about having an extra category?
I'm not aware of any real costs involved, or real reasons to use
categories scarcely.
> * The name also suggests to me that it will control sys-*
> implementations, but the victims so far are all app-*. Obviously,
> we don't want twenty *-meta categories though.
>
> * The -meta prefix is already used in a bunch of ebuilds to mean
> something different. The packages in sys-meta won't be
> "metapackages" in the same sense.
I don't really care how it's named. I've chosen "sys-" because in my
PoC it happens to control tools that are part of the base system.
I suppose we could also want it for less important stuff like notify-
send (though I guess I'll lastrite that eselect anyway). I think we
should just use one category for all of them, and I'm open to a better
name.
> * Should we replace app-arch/tar with sys-meta/tar in @system?
I think that makes sense for a long-term goal, unless there's a good
reason to always have gtar around. It should be noted that this will
require adding explicitly dependencies to some packages.
>
> * Having to specify the relationship twice (once in the sys-meta
> package and once in each implementation) is also a bit ugly, as is
> having to account for the symlink not being installed (yet) in
> each implementation's pkg_postinst. This made me wonder, could
> the RDEPEND/PDEPEND be reversed? In other words, could (say) GNU
> tar require that the symlink be present immediately, but the
> metapackage only require that some implementation be merged
> eventually?
>
> To answer my own question, the PMS says that PDEPENDs "must be
> installed at some point before the package manager finishes the
> batch of installs," which would be problematic if some later
> package in the batch actually needed a tar implementation
> available to build. We can't change the PMS, so installing a
> symlink in the implementation ebuilds avoids the issue, but still
> eventually cedes control to the sys-meta package.
>
> I guess you already thought through all of that? If so, it would be
> nice to have the rationale written down somewhere that we can refer
> back to.
Yes, I thought how to do it and I think the current implementation is
the best we can. The most important point is avoiding a long period
without system tools being available during the transition, and I think
pkg_postinst() approach handles that best.
> * Is it worth thinking about improvements to EAPI=? that could help
> us here? By e.g. allowing virtuals to install symlinks, or by
> making PDEPEND kick in sooner (after this package, but before the
> rest of the batch)?
>
PMS doesn't say anything about (new-style) virtuals. It's a Gentoo
policy entirely.
Improving PDEPEND would be also helpful e.g. for clang/clang-runtime
cycle. Unfortunately, it's non-trivial since PDEPENDs can have their
own dependencies that can affect the build order in mysterious ways.
Dependency resolver is not really my area of expertise.
--
Best regards,
Michał Górny
