Re: [gentoo-dev] [RFC] sys-meta/* to own and control /bin/{cpio,sh,tar,...} symlinks (alternatives-ish)

[Michał Górny]

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