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?
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.
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.
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?
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.
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.
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.
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.
On 15/02/2023 15:51, Daniel Frey wrote:
On 2/15/23 06:10, Michael Orlitzky wrote:what are they going to do about "eselect kernel set ..." then?
On 2023-02-15 08:11:46, Neil Bothwick wrote:I didn't even know eselect-whatever was even an option until this
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.
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.
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 :-)
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 :-)
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.
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.
Sysop: | Keyop |
---|---|
Location: | Huddersfield, West Yorkshire, UK |
Users: | 546 |
Nodes: | 16 (2 / 14) |
Uptime: | 06:12:20 |
Calls: | 10,386 |
Calls today: | 1 |
Files: | 14,058 |
Messages: | 6,416,633 |