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

[Michael Orlitzky]

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.

  * 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.

  * Should we replace app-arch/tar with sys-meta/tar in @system?

  * 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.

  * 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)?

Despite all the skeptical-sounding feedback, I think this is a good
idea, and an improvement over eselect.