* [gentoo-dev] [RFC] sys-meta/* to own and control /bin/{cpio,sh,tar,...} symlinks (alternatives-ish)
@ 2022-11-23 7:38 Michał Górny
2022-11-23 13:47 ` Michael Orlitzky
` (3 more replies)
0 siblings, 4 replies; 19+ messages in thread
From: Michał Górny @ 2022-11-23 7:38 UTC (permalink / raw
To: gentoo-dev
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
What are the problems being solved?
===================================
We currently provide a certain degree of non-GNU userland support.
However, for a long time we have been more GNU-centric in some areas
than in other.
It has been an acceptable practice to replace the /bin/sh symlink to
point to dash for quite a while now. This eventually led me to adding
app-eselect/eselect-sh to streamline the support.
Recently we've "renamed" a bunch of common GNU tools (cpio, patch, sed,
tar...) to g-prefixed variants. For example, app-arch/tar now installs
`gtar` executable and a `tar -> gtar` symlink. The next step is actively
allowing people to replace the symlink with bsdcpio/bsdtar from
libarchive.
This is not only about "choice". For example, GNU cpio is a very bad
quality software, with practically all Linux distributions applying
a pile of security fixes.
How are they being solved?
==========================
We add a bunch of sys-meta/* packages that serve twofold function: they
install symlinks for "base system tools" that point to the
implementation selected via USE flags, and they depend on the provider
via RDEPEND.
sys-meta/sh provides USE flags for different shells supported as /bin/sh
target, with bash being the default. After installing, it takes
ownership of /bin/sh and replaces it with the correct symlink.
sys-meta/cpio and sys-meta/tar install the respective tool symlinks.
They replace the symlinks currently installed by app-arch/cpio
and app-arch/tar respectively, making the replacement "relatively safe"
via weak blockers.
What are the advantages of proposed solution over eselect?
==========================================================
1. It provides central ownership for the symlinks, and preservation of
the preferred variant.
2. It blocks you from unmerging the active implementation (via RDEPEND)
and leaving the symlink broken (unless all implementations are
explicitly eselect-aware).
3. It avoids writing to /bin outside package manager control (think
read-only rootfs that's only updated via PM).
4. It makes it possible to distinguish dependencies on generic tools vs.
specific implementation. Right now a dependency on "app-arch/tar"
usually triggers a "it's in @system, so remove it" response. Now "app-
arch/tar" will mean "I need GNU tar (i.e. I call `gtar`) specifically",
--
Best regards,
Michał Górny
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [gentoo-dev] [RFC] sys-meta/* to own and control /bin/{cpio,sh,tar,...} symlinks (alternatives-ish)
2022-11-23 7:38 [gentoo-dev] [RFC] sys-meta/* to own and control /bin/{cpio,sh,tar,...} symlinks (alternatives-ish) Michał Górny
@ 2022-11-23 13:47 ` Michael Orlitzky
2022-11-23 14:37 ` Michał Górny
2022-11-23 13:58 ` Piotr Karbowski
` (2 subsequent siblings)
3 siblings, 1 reply; 19+ messages in thread
From: Michael Orlitzky @ 2022-11-23 13:47 UTC (permalink / raw
To: gentoo-dev
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.
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [gentoo-dev] [RFC] sys-meta/* to own and control /bin/{cpio,sh,tar,...} symlinks (alternatives-ish)
2022-11-23 7:38 [gentoo-dev] [RFC] sys-meta/* to own and control /bin/{cpio,sh,tar,...} symlinks (alternatives-ish) Michał Górny
2022-11-23 13:47 ` Michael Orlitzky
@ 2022-11-23 13:58 ` Piotr Karbowski
2022-11-23 14:26 ` Michał Górny
2022-11-23 16:32 ` Ionen Wolkens
2022-11-23 17:48 ` Michael Orlitzky
2022-11-24 16:29 ` Michał Górny
3 siblings, 2 replies; 19+ messages in thread
From: Piotr Karbowski @ 2022-11-23 13:58 UTC (permalink / raw
To: gentoo-dev
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?
-- Piotr.
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [gentoo-dev] [RFC] sys-meta/* to own and control /bin/{cpio,sh,tar,...} symlinks (alternatives-ish)
2022-11-23 13:58 ` Piotr Karbowski
@ 2022-11-23 14:26 ` Michał Górny
2022-11-23 16:32 ` Ionen Wolkens
1 sibling, 0 replies; 19+ messages in thread
From: Michał Górny @ 2022-11-23 14:26 UTC (permalink / raw
To: gentoo-dev
On Wed, 2022-11-23 at 14:58 +0100, Piotr Karbowski wrote:
> 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?
No, I don't think that's going to happen. Sure, switching that will
make sense for some packages; for others, eselect will probably be
better.
--
Best regards,
Michał Górny
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [gentoo-dev] [RFC] sys-meta/* to own and control /bin/{cpio,sh,tar,...} symlinks (alternatives-ish)
2022-11-23 13:47 ` Michael Orlitzky
@ 2022-11-23 14:37 ` Michał Górny
2022-11-23 14:58 ` Michael Orlitzky
2022-11-23 15:49 ` Ionen Wolkens
0 siblings, 2 replies; 19+ messages in thread
From: Michał Górny @ 2022-11-23 14:37 UTC (permalink / raw
To: gentoo-dev
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
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [gentoo-dev] [RFC] sys-meta/* to own and control /bin/{cpio,sh,tar,...} symlinks (alternatives-ish)
2022-11-23 14:37 ` Michał Górny
@ 2022-11-23 14:58 ` Michael Orlitzky
2022-11-23 16:45 ` Ulrich Mueller
2022-11-23 15:49 ` Ionen Wolkens
1 sibling, 1 reply; 19+ messages in thread
From: Michael Orlitzky @ 2022-11-23 14:58 UTC (permalink / raw
To: gentoo-dev
On Wed, 2022-11-23 at 15:37 +0100, Michał Górny wrote:
>
>
> PMS doesn't say anything about (new-style) virtuals. It's a Gentoo
> policy entirely.
This is listed as a retroactive change,
Note: A ‘new-style virtual’ is a normal package that installs no
files and uses its dependency requirements to pull in a ‘provider’.
> 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 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/ ?
Regardless, since I specifically called out the "meta" suffix, let me
put forward sys-alternatives as an alternative.
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [gentoo-dev] [RFC] sys-meta/* to own and control /bin/{cpio,sh,tar,...} symlinks (alternatives-ish)
2022-11-23 14:37 ` Michał Górny
2022-11-23 14:58 ` Michael Orlitzky
@ 2022-11-23 15:49 ` Ionen Wolkens
2022-11-23 17:36 ` Ionen Wolkens
2022-11-24 0:14 ` Yuan Liao (Leo)
1 sibling, 2 replies; 19+ messages in thread
From: Ionen Wolkens @ 2022-11-23 15:49 UTC (permalink / raw
To: gentoo-dev
[-- Attachment #1: Type: text/plain, Size: 1115 bytes --]
On Wed, Nov 23, 2022 at 03:37:57PM +0100, Michał Górny wrote:
> > * 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.
Not seeing an issue with a new category myself, I'd rather these
be split to avoid confusion and it be clear for users what it is.
Not sure for a better name though, alternatives/tar? Haven't really
thought about it, but technically no need for a prefix- like virtual.
--
ionen
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [gentoo-dev] [RFC] sys-meta/* to own and control /bin/{cpio,sh,tar,...} symlinks (alternatives-ish)
2022-11-23 13:58 ` Piotr Karbowski
2022-11-23 14:26 ` Michał Górny
@ 2022-11-23 16:32 ` Ionen Wolkens
1 sibling, 0 replies; 19+ messages in thread
From: Ionen Wolkens @ 2022-11-23 16:32 UTC (permalink / raw
To: gentoo-dev
[-- Attachment #1: Type: text/plain, Size: 978 bytes --]
On Wed, Nov 23, 2022 at 02:58:14PM +0100, Piotr Karbowski wrote:
> 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?
There's some that do nothing but modify config files (e.g. eselect
editor, even has freestyle which couldn't express as USE), and there's
other over-the-top stuff like Wine or gcc (between wine variants, and
crossdev gcc, feel managing sys-meta and switching on the fly would
get annoying).
So yeah, think both type have a place.
On Wine note, new eselect-wine-2 won't modify /usr anymore and it's
easy to track/cleanup/reset what it modifies now -- something eselect
can try to aim for in general.
--
ionen
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [gentoo-dev] [RFC] sys-meta/* to own and control /bin/{cpio,sh,tar,...} symlinks (alternatives-ish)
2022-11-23 14:58 ` Michael Orlitzky
@ 2022-11-23 16:45 ` Ulrich Mueller
2022-11-24 1:32 ` Alexey Sokolov
0 siblings, 1 reply; 19+ messages in thread
From: Ulrich Mueller @ 2022-11-23 16:45 UTC (permalink / raw
To: Michael Orlitzky; +Cc: gentoo-dev
[-- Attachment #1: Type: text/plain, Size: 776 bytes --]
>>>>> 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
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 507 bytes --]
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [gentoo-dev] [RFC] sys-meta/* to own and control /bin/{cpio,sh,tar,...} symlinks (alternatives-ish)
2022-11-23 15:49 ` Ionen Wolkens
@ 2022-11-23 17:36 ` Ionen Wolkens
2022-11-24 0:14 ` Yuan Liao (Leo)
1 sibling, 0 replies; 19+ messages in thread
From: Ionen Wolkens @ 2022-11-23 17:36 UTC (permalink / raw
To: gentoo-dev
[-- Attachment #1: Type: text/plain, Size: 696 bytes --]
On Wed, Nov 23, 2022 at 10:49:20AM -0500, Ionen Wolkens wrote:
> Not sure for a better name though, alternatives/tar? Haven't really
> thought about it, but technically no need for a prefix- like virtual.
For something shorter, select/tar maybe. Or select-meta if want
to keep a more common - style.
app-meta could also get awkward if we do this with libraries.
Kind of like the idea of having something to describe what users
should expect from this (select/alt). But if we want a general
purpose meta category that could be used for about anything like
virtual but without PMS restrictions, then that doesn't really work
(could even go ahead and call it 'meta').
--
ionen
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [gentoo-dev] [RFC] sys-meta/* to own and control /bin/{cpio,sh,tar,...} symlinks (alternatives-ish)
2022-11-23 7:38 [gentoo-dev] [RFC] sys-meta/* to own and control /bin/{cpio,sh,tar,...} symlinks (alternatives-ish) Michał Górny
2022-11-23 13:47 ` Michael Orlitzky
2022-11-23 13:58 ` Piotr Karbowski
@ 2022-11-23 17:48 ` Michael Orlitzky
2022-11-24 16:29 ` Michał Górny
3 siblings, 0 replies; 19+ messages in thread
From: Michael Orlitzky @ 2022-11-23 17:48 UTC (permalink / raw
To: gentoo-dev
On Wed, 2022-11-23 at 08:38 +0100, Michał Górny wrote:
>
> What are the advantages of proposed solution over eselect?
> ==========================================================
I think it's also worth mentioning the advantages over the usual
virtual approach, where we have a virtual pull in one implementation
and the implementations be responsible for the symlink. Because
otherwise that would tick the same boxes.
Here's one: the sys-meta approach allows you to switch the
implementation quickly without rebuilding an entire package. For
example, if I meet a package that's broken with /bin/sh -> /bin/dash, I
don't want to have to emerge bash to get past that.
Maybe there are others.
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [gentoo-dev] [RFC] sys-meta/* to own and control /bin/{cpio,sh,tar,...} symlinks (alternatives-ish)
2022-11-23 15:49 ` Ionen Wolkens
2022-11-23 17:36 ` Ionen Wolkens
@ 2022-11-24 0:14 ` Yuan Liao (Leo)
1 sibling, 0 replies; 19+ messages in thread
From: Yuan Liao (Leo) @ 2022-11-24 0:14 UTC (permalink / raw
To: gentoo-dev
On Wed, Nov 23, 2022 at 7:49 AM Ionen Wolkens <ionen@gentoo.org> wrote:
> Not sure for a better name though, alternatives/tar? Haven't really
> thought about it, but technically no need for a prefix- like virtual.
What about 'sys-symlinks' or something similar which indicates that
packages in the category just install symlinks? Pretty
self-explanatory.
Leo3418
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [gentoo-dev] [RFC] sys-meta/* to own and control /bin/{cpio,sh,tar,...} symlinks (alternatives-ish)
2022-11-23 16:45 ` Ulrich Mueller
@ 2022-11-24 1:32 ` Alexey Sokolov
2022-11-24 2:05 ` Ionen Wolkens
0 siblings, 1 reply; 19+ messages in thread
From: Alexey Sokolov @ 2022-11-24 1:32 UTC (permalink / raw
To: gentoo-dev
23.11.2022 16:45, Ulrich Mueller пишет:
>>>>>> 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
Since these packages manage symlinks, make it app-symlink?
--
Best regards,
Alexey "DarthGandalf" Sokolov
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [gentoo-dev] [RFC] sys-meta/* to own and control /bin/{cpio,sh,tar,...} symlinks (alternatives-ish)
2022-11-24 1:32 ` Alexey Sokolov
@ 2022-11-24 2:05 ` Ionen Wolkens
2022-11-24 2:10 ` Ionen Wolkens
2022-11-24 4:01 ` Maciej Barć
0 siblings, 2 replies; 19+ messages in thread
From: Ionen Wolkens @ 2022-11-24 2:05 UTC (permalink / raw
To: gentoo-dev
[-- Attachment #1: Type: text/plain, Size: 1079 bytes --]
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
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [gentoo-dev] [RFC] sys-meta/* to own and control /bin/{cpio,sh,tar,...} symlinks (alternatives-ish)
2022-11-24 2:05 ` Ionen Wolkens
@ 2022-11-24 2:10 ` Ionen Wolkens
2022-11-24 4:01 ` Maciej Barć
1 sibling, 0 replies; 19+ messages in thread
From: Ionen Wolkens @ 2022-11-24 2:10 UTC (permalink / raw
To: gentoo-dev
[-- Attachment #1: Type: text/plain, Size: 1374 bytes --]
On Wed, Nov 23, 2022 at 09:05:47PM -0500, Ionen Wolkens wrote:
> 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?
Then again, I guess installing a wrapper / config files, etc... won't
fall under metapackage anymore, given installing code vs just making a
symlink.
>
> 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
--
ionen
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [gentoo-dev] [RFC] sys-meta/* to own and control /bin/{cpio,sh,tar,...} symlinks (alternatives-ish)
2022-11-24 2:05 ` Ionen Wolkens
2022-11-24 2:10 ` Ionen Wolkens
@ 2022-11-24 4:01 ` Maciej Barć
1 sibling, 0 replies; 19+ messages in thread
From: Maciej Barć @ 2022-11-24 4:01 UTC (permalink / raw
To: gentoo-dev; +Cc: Ionen Wolkens
[-- Attachment #1.1.1: Type: text/plain, Size: 1340 bytes --]
> app -> what if it's library alternatives?
Maybe split to "app-" and "lib-" then?
Also, what about "-alt"? So "app-alt" and "lib-alt".
On 11/24/22 03:05, Ionen Wolkens wrote:
> 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.
--
Have a great day!
~ Maciej XGQT Barć
[-- Attachment #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 6297 bytes --]
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 495 bytes --]
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [gentoo-dev] [RFC] sys-meta/* to own and control /bin/{cpio,sh,tar,...} symlinks (alternatives-ish)
2022-11-23 7:38 [gentoo-dev] [RFC] sys-meta/* to own and control /bin/{cpio,sh,tar,...} symlinks (alternatives-ish) Michał Górny
` (2 preceding siblings ...)
2022-11-23 17:48 ` Michael Orlitzky
@ 2022-11-24 16:29 ` Michał Górny
2022-11-24 17:25 ` Maciej Barć
3 siblings, 1 reply; 19+ messages in thread
From: Michał Górny @ 2022-11-24 16:29 UTC (permalink / raw
To: gentoo-dev
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.
--
Best regards,
Michał Górny
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [gentoo-dev] [RFC] sys-meta/* to own and control /bin/{cpio,sh,tar,...} symlinks (alternatives-ish)
2022-11-24 16:29 ` Michał Górny
@ 2022-11-24 17:25 ` Maciej Barć
2022-11-24 19:01 ` Alec Warner
0 siblings, 1 reply; 19+ messages in thread
From: Maciej Barć @ 2022-11-24 17:25 UTC (permalink / raw
To: gentoo-dev, Michał Górny
[-- Attachment #1.1.1: Type: text/plain, Size: 614 bytes --]
> 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ć
[-- Attachment #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 6297 bytes --]
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 495 bytes --]
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [gentoo-dev] [RFC] sys-meta/* to own and control /bin/{cpio,sh,tar,...} symlinks (alternatives-ish)
2022-11-24 17:25 ` Maciej Barć
@ 2022-11-24 19:01 ` Alec Warner
0 siblings, 0 replies; 19+ messages in thread
From: Alec Warner @ 2022-11-24 19:01 UTC (permalink / raw
To: gentoo-dev; +Cc: Michał Górny
On Thu, Nov 24, 2022 at 9:25 AM Maciej Barć <xgqt@gentoo.org> wrote:
>
> > Let's go for a compromise, and combine your naming suggestions into
> > "alt-symlinks".
>
> Perfect, the worst of both worlds! :^D
You know a compromise is when everyone leaves unhappy ;)
-A
>
> 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ć
^ permalink raw reply [flat|nested] 19+ messages in thread
end of thread, other threads:[~2022-11-24 19:01 UTC | newest]
Thread overview: 19+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2022-11-23 7:38 [gentoo-dev] [RFC] sys-meta/* to own and control /bin/{cpio,sh,tar,...} symlinks (alternatives-ish) Michał Górny
2022-11-23 13:47 ` Michael Orlitzky
2022-11-23 14:37 ` Michał Górny
2022-11-23 14:58 ` Michael Orlitzky
2022-11-23 16:45 ` Ulrich Mueller
2022-11-24 1:32 ` Alexey Sokolov
2022-11-24 2:05 ` Ionen Wolkens
2022-11-24 2:10 ` Ionen Wolkens
2022-11-24 4:01 ` Maciej Barć
2022-11-23 15:49 ` Ionen Wolkens
2022-11-23 17:36 ` Ionen Wolkens
2022-11-24 0:14 ` Yuan Liao (Leo)
2022-11-23 13:58 ` Piotr Karbowski
2022-11-23 14:26 ` Michał Górny
2022-11-23 16:32 ` Ionen Wolkens
2022-11-23 17:48 ` Michael Orlitzky
2022-11-24 16:29 ` Michał Górny
2022-11-24 17:25 ` Maciej Barć
2022-11-24 19:01 ` Alec Warner
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox