Mailing List Archive

Is it OK to get rid of app-alternatives/* ?
A whole bunch of busy-work for emerge, and nothing in the news item
indicates it's really necessary for the average user. Howsabout...

* manually zapping with "rm -rf /var/db/repos/gentoo/app-alternatives"
* and then include "app-alternatives" in the file pointed to by
PORTAGE_RSYNC_EXTRA_OPTS="--exclude-from=<whatever>"

Am I missing something obvious that would cause problems?

--
I've seen things, you people wouldn't believe; Gopher, Netscape with
frames, the first Browser Wars. Searching for pages with AltaVista,
pop-up windows self-replicating, trying to uninstall RealPlayer. All
those moments, will be lost in time like tears in rain... time to die.
Re: Is it OK to get rid of app-alternatives/* ? [ In reply to ]
Dave

On Tue, Feb 14, 2023, 20:47 Walter Dnes <waltdnes@waltdnes.org> wrote:

> A whole bunch of busy-work for emerge, and nothing in the news item
> indicates it's really necessary for the average user. Howsabout...
>
> * manually zapping with "rm -rf /var/db/repos/gentoo/app-alternatives"
> * and then include "app-alternatives" in the file pointed to by
> PORTAGE_RSYNC_EXTRA_OPTS="--exclude-from=<whatever>"
>
> Am I missing something obvious that would cause problems?
>
> --
> I've seen things, you people wouldn't believe; Gopher, Netscape with
> frames, the first Browser Wars. Searching for pages with AltaVista,
> pop-up windows self-replicating, trying to uninstall RealPlayer. All
> those moments, will be lost in time like tears in rain... time to die.
>
>
Re: Is it OK to get rid of app-alternatives/* ? [ In reply to ]
On 2/14/23 20:47, Walter Dnes wrote:
> A whole bunch of busy-work for emerge, and nothing in the news item
> indicates it's really necessary for the average user. Howsabout...
>
> * manually zapping with "rm -rf /var/db/repos/gentoo/app-alternatives"
> * and then include "app-alternatives" in the file pointed to by
> PORTAGE_RSYNC_EXTRA_OPTS="--exclude-from=<whatever>"
>
> Am I missing something obvious that would cause problems?
>
You're missing a lot of manual busy work you would have to do
maintaining a package.provided since packages depend on stuff in that
category.
Re: Is it OK to get rid of app-alternatives/* ? [ In reply to ]
On Tue, Feb 14, 2023 at 08:57:48PM -0500, Michael Cook wrote
> On 2/14/23 20:47, Walter Dnes wrote:
> >
> > Am I missing something obvious that would cause problems?
> >
> You're missing a lot of manual busy work you would have to do
> maintaining a package.provided since packages depend on stuff in
> that category.

After thoroughly reading the docs at...
https://www.gentoo.org/support/news-items/2022-12-27-alternatives-introduction.html
it looks like the hand of him-who-must-not-be-named. Rather than
provide special support for the 1% extreme edge cases, the remaining 99%
of regular users will be dragged through the change. More bloat; and
eselect is on the road to eventual deprecation. With that in mind, I
don't really have any choice but to go along. I'll have to change my
sig to include something about a fully functional linux on a 16
*MEGA*byte machine running X (Yes, I actually was doing that back in
2000)... sigh.

--
I've seen things, you people wouldn't believe; Gopher, Netscape with
frames, the first Browser Wars. Searching for pages with AltaVista,
pop-up windows self-replicating, trying to uninstall RealPlayer. All
those moments, will be lost in time like tears in rain... time to die.
Re: Is it OK to get rid of app-alternatives/* ? [ In reply to ]
On Wed, 15 Feb 2023 02:44:47 -0500, Walter Dnes wrote:

> After thoroughly reading the docs at...
> https://www.gentoo.org/support/news-items/2022-12-27-alternatives-introduction.html
> it looks like the hand of him-who-must-not-be-named. Rather than
> provide special support for the 1% extreme edge cases, the remaining 99%
> of regular users will be dragged through the change. More bloat; and
> eselect is on the road to eventual deprecation.

"Systems will be more robust and desired system configuration
can be achieved using the package manager rather than manual steps
outside of it."

Sounds quite reasonable to me. As does being able to control everything
from within Portage, with USE flags, rather than messing around with
eselect.

If, as you say, it will eventually replace eselect, there is no more
bloat, just different bloat. It's still just a bunch of symlinks, but
managed differently.


--
Neil Bothwick

Inland Revenue: We've got what it takes to take what you've got!
Re: Is it OK to get rid of app-alternatives/* ? [ In reply to ]
Hi,

"Walter Dnes" <waltdnes@waltdnes.org> writes:

> A whole bunch of busy-work for emerge, and nothing in the news item
> indicates it's really necessary for the average user. Howsabout...

It's definitely necessary. Those packages provide links for vital parts
of the filesystem, like /bin/sh.

Why do you want to remove them? If there's something we failed to
consider when implementing app-alternatives, please let us know and
we'll try to rectify the issue.

> * manually zapping with "rm -rf /var/db/repos/gentoo/app-alternatives"
> * and then include "app-alternatives" in the file pointed to by
> PORTAGE_RSYNC_EXTRA_OPTS="--exclude-from=<whatever>"
>
> Am I missing something obvious that would cause problems?

Have a great day.
--
Arsen Arsenovi?
Re: Is it OK to get rid of app-alternatives/* ? [ In reply to ]
On 2023-02-15 08:11:46, Neil Bothwick wrote:
>
> If, as you say, it will eventually replace eselect, there is no more
> bloat, just different bloat. It's still just a bunch of symlinks, but
> managed differently.
>

Should be less, since you already have portage installed but not
necessarily eselect-whatever.
Re: Is it OK to get rid of app-alternatives/* ? [ In reply to ]
On Wed, Feb 15, 2023 at 9:10 AM Michael Orlitzky <mjo@gentoo.org> wrote:
>
> On 2023-02-15 08:11:46, Neil Bothwick wrote:
> >
> > If, as you say, it will eventually replace eselect, there is no more
> > bloat, just different bloat. It's still just a bunch of symlinks, but
> > managed differently.
> >
>
> Should be less, since you already have portage installed but not
> necessarily eselect-whatever.
>

The symlinks are all associated with packages as well, which means
that when you uninstall things that will get rid of the symlinks as
well. This is really just a best practice all-around. I have a
Gentoo system I've been maintaining for a while and I occasionally
find orphaned stuff poking around because of special cases of things
that weren't managed by the package manager, and so when things were
obsoleted they stuck around.

The news is needed precisely because the migration involves having the
package manager install a bunch of stuff over files not owned by any
package. That triggers a warning, but only because the files were in
a less than ideal state to start.

Things like this and the new user/group packages also reduce the
complexity of dependency management because they just turn everything
into a package dependency. Less special cases.

--
Rich
Re: Is it OK to get rid of app-alternatives/* ? [ In reply to ]
On 2/15/23 06:10, Michael Orlitzky wrote:
> On 2023-02-15 08:11:46, Neil Bothwick wrote:
>>
>> If, as you say, it will eventually replace eselect, there is no more
>> bloat, just different bloat. It's still just a bunch of symlinks, but
>> managed differently.
>>
>
> Should be less, since you already have portage installed but not
> necessarily eselect-whatever.
>

I didn't even know eselect-whatever was even an option until this
post... It's not something I've ever used.

It does (at least to me) make sense for the package manager to enforce
these selections rather than some optional tool though.

Dan
Re: Is it OK to get rid of app-alternatives/* ? [ In reply to ]
On 15/02/2023 15:51, Daniel Frey wrote:
> On 2/15/23 06:10, Michael Orlitzky wrote:
>> On 2023-02-15 08:11:46, Neil Bothwick wrote:
>>>
>>> If, as you say, it will eventually replace eselect, there is no more
>>> bloat, just different bloat. It's still just a bunch of symlinks, but
>>> managed differently.
>>>
>>
>> Should be less, since you already have portage installed but not
>> necessarily eselect-whatever.
>>
>
> I didn't even know eselect-whatever was even an option until this
> post... It's not something I've ever used.
>
> It does (at least to me) make sense for the package manager to enforce
> these selections rather than some optional tool though.
>
what are they going to do about "eselect kernel set ..." then?

It's bad enough depclean deleting the active kernel if you don't watch
out, without something deciding to install a non-existent kernel and
deleting the live one :-)

Cheers,
Wol
Re: Is it OK to get rid of app-alternatives/* ? [ In reply to ]
Hi,

Wol <antlists@youngman.org.uk> writes:

> On 15/02/2023 15:51, Daniel Frey wrote:
>> On 2/15/23 06:10, Michael Orlitzky wrote:
>>> On 2023-02-15 08:11:46, Neil Bothwick wrote:
>>>>
>>>> If, as you say, it will eventually replace eselect, there is no more
>>>> bloat, just different bloat. It's still just a bunch of symlinks, but
>>>> managed differently.
>>>>
>>>
>>> Should be less, since you already have portage installed but not
>>> necessarily eselect-whatever.
>>>
>> I didn't even know eselect-whatever was even an option until this
>> post... It's not something I've ever used.
>> It does (at least to me) make sense for the package manager to enforce these
>> selections rather than some optional tool though.
>>
> what are they going to do about "eselect kernel set ..." then?
>
> It's bad enough depclean deleting the active kernel if you don't watch out,
> without something deciding to install a non-existent kernel and deleting the
> live one :-)

This is part of the motivation behind the dist-kernel project. See:
https://wiki.gentoo.org/wiki/Project:Distribution_Kernel

As an anecdote, I haven't thought about what my kernel and modules are
doing in a very long time, and I use multiple out of tree modules.

Happy hacking and have a great day.
--
Arsen Arsenovi?
Re: Is it OK to get rid of app-alternatives/* ? [ In reply to ]
On Wed, Feb 15, 2023 at 07:20:37PM +0000, Wol wrote

> what are they going to do about "eselect kernel set ..." then?
>
> It's bad enough depclean deleting the active kernel if you don't watch
> out, without something deciding to install a non-existent kernel and
> deleting the live one :-)

I have my own hand-coded script that runs "emerge --pretend --depclean"
and tweaks/filters the output into another script called "cleanscript".
I've set it to filter out "gentoo-sources". I then inspect
"cleanscript" before running it. And, oh yeah, depclean wants to remove
nano. I had to "emerge -n nano" to protect it.

--
I've seen things, you people wouldn't believe; Gopher, Netscape with
frames, the first Browser Wars. Searching for pages with AltaVista,
pop-up windows self-replicating, trying to uninstall RealPlayer. All
those moments, will be lost in time like tears in rain... time to die.
Re: Is it OK to get rid of app-alternatives/* ? [ In reply to ]
On Wed, 15 Feb 2023 23:09:54 -0500, Walter Dnes wrote:

> > It's bad enough depclean deleting the active kernel if you don't
> > watch out, without something deciding to install a non-existent
> > kernel and deleting the live one :-)
>
> I have my own hand-coded script that runs "emerge --pretend
> --depclean" and tweaks/filters the output into another script called
> "cleanscript". I've set it to filter out "gentoo-sources". I then
> inspect "cleanscript" before running it. And, oh yeah, depclean wants
> to remove nano. I had to "emerge -n nano" to protect it.

You can add kernel sources to a set so they are never depcleaned

% cat sets.conf
[kernels]
class = portage.sets.dbapi.OwnerSet
world-candidate = False
files = /usr/src

Then emerge -n @kernels

I do the same with gcc so I can keep the previous version

[gcc]
class = portage.sets.dbapi.OwnerSet
world-candidate = False
files = /usr/x86_64-pc-linux-gnu/gcc-bin


--
Neil Bothwick

For security reasons, all text in this mail
is double-rot13 encrypted.
Re: Is it OK to get rid of app-alternatives/* ? [ In reply to ]
Thanks

Dave

On Sun, Feb 19, 2023, 05:31 Neil Bothwick <neil@digimed.co.uk> wrote:

> On Wed, 15 Feb 2023 23:09:54 -0500, Walter Dnes wrote:
>
> > > It's bad enough depclean deleting the active kernel if you don't
> > > watch out, without something deciding to install a non-existent
> > > kernel and deleting the live one :-)
> >
> > I have my own hand-coded script that runs "emerge --pretend
> > --depclean" and tweaks/filters the output into another script called
> > "cleanscript". I've set it to filter out "gentoo-sources". I then
> > inspect "cleanscript" before running it. And, oh yeah, depclean wants
> > to remove nano. I had to "emerge -n nano" to protect it.
>
> You can add kernel sources to a set so they are never depcleaned
>
> % cat sets.conf
> [kernels]
> class = portage.sets.dbapi.OwnerSet
> world-candidate = False
> files = /usr/src
>
> Then emerge -n @kernels
>
> I do the same with gcc so I can keep the previous version
>
> [gcc]
> class = portage.sets.dbapi.OwnerSet
> world-candidate = False
> files = /usr/x86_64-pc-linux-gnu/gcc-bin
>
>
> --
> Neil Bothwick
>
> For security reasons, all text in this mail
> is double-rot13 encrypted.
>