[gentoo-user] Is it OK to get rid of app-alternatives/* ?

[Walter Dnes]

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?

[David Rosenbaum]

Dave

Post by Walter Dnes
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.

[Michael Cook]

Post by Walter Dnes
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.

[Walter Dnes]

Post by Michael Cook

Post by Walter Dnes
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.

[Neil Bothwick]

Post by Walter Dnes
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.

[Michael Orlitzky]

Post by Neil Bothwick
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.

[Rich Freeman]

Post by Michael Orlitzky

Post by Neil Bothwick
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.

[Daniel Frey]

Post by Michael Orlitzky

Post by Neil Bothwick
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

[Wol]

Post by Daniel Frey

Post by Michael Orlitzky

Post by Neil Bothwick
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

[Arsen Arsenović]

Hi,

Post by Wol

Post by Daniel Frey

Post by Michael Orlitzky

Post by Neil Bothwick
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.

[Walter Dnes]

Post by Wol
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.

[Neil Bothwick]

Post by Walter Dnes

Post by Wol
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

[David Rosenbaum]

Thanks

Dave

Post by Neil Bothwick

Post by Walter Dnes

Post by Wol
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
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.

[Arsen Arsenović]

Hi,

Post by Walter Dnes
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.

Post by Walter Dnes
* 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.