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.
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
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)?
Hi,
On 23/11/2022 08.38, 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.
I am very much in favour to have a package that controls those symlinks. What is not immediately clear to me is what would that mean for eselect
in long run. Is it so that you'd like to keep eselect around and alive parallel to those sys-meta category packages, or would there be push to eventually get rid of most of eselect and where possible switch to sys-meta?
PMS doesn't say anything about (new-style) virtuals. It's a Gentoo
policy entirely.
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.
...
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.
* 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.
On Wed, 23 Nov 2022, Michael Orlitzky wrote:
The main reason the new category is distasteful to me is because it's
*so close* to being a virtual. For one, having these packages be
virtuals would make them somewhat self-explanatory to end users. If
we're collectively willing to overlook the "no files" bit, are there
any other reasons to avoid using virtual/ ?
I am very much in favour to have a package that controls those symlinks. What is not immediately clear to me is what would that mean for eselect
in long run. Is it so that you'd like to keep eselect around and alive parallel to those sys-meta category packages, or would there be push to eventually get rid of most of eselect and where possible switch to sys-meta?
What are the advantages of proposed solution over eselect? ==========================================================
Not sure for a better name though, alternatives/tar? Haven't really
thought about it, but technically no need for a prefix- like virtual.
Not sure for a better name though, alternatives/tar? Haven't really
thought about it, but technically no need for a prefix- like virtual.
On Wed, 23 Nov 2022, Michael Orlitzky wrote:
The main reason the new category is distasteful to me is because it's
*so close* to being a virtual. For one, having these packages be
virtuals would make them somewhat self-explanatory to end users. If
we're collectively willing to overlook the "no files" bit, are there
any other reasons to avoid using virtual/ ?
They have a nonempty installation image and at least one phase function, therefore they're not virtuals. IIRC there are also some optimisations
for the virtual category in Portage as well as in our QA tools which
rely on this.
However, I tend to agree that the category should be named app-meta
rather than sys-meta, because chances are that non-system packages will
also make use of it.
Ulrich
However, I tend to agree that the category should be named app-meta
rather than sys-meta, because chances are that non-system packages will also make use of it.
Ulrich
Since these packages manage symlinks, make it app-symlink?
On Thu, Nov 24, 2022 at 01:32:04AM +0000, Alexey Sokolov wrote:
However, I tend to agree that the category should be named app-meta rather than sys-meta, because chances are that non-system packages will also make use of it.
Ulrich
Since these packages manage symlinks, make it app-symlink?
Mentioned this in another post, but this is limiting what would make
sense to be in there further.
app -> what if it's library alternatives?
symlink -> what if we need to use wrappers or some other solution?
Not that we ever really match categories perfectly either way, but
may as well stay generic rather than mismatch or create multiple
sub-types.
Some random ideas I had were 'alternatives', 'meta', 'select'
'select-meta', not that I thought much about it.
'meta' would essentially be like an entirely generic 'virtual' but
just without PMS restrictions. While the ones with alternatives or
select are more descriptive of what it's for without saying anything
about how we're doing it or for what type of package.
--
ionen
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
Let's go for a compromise, and combine your naming suggestions into "alt-symlinks".
Perfect, the worst of both worlds! :^D
On 11/24/22 17:29, Michał Górny 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
Let's go for a compromise, and combine your naming suggestions into "alt-symlinks".
/me hides.
--
Have a great day!
~ Maciej XGQT Barć
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 407 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 15:20:51 |
| Calls: | 8,555 |
| Calls today: | 7 |
| Files: | 13,219 |
| Messages: | 5,925,665 |