[gentoo-user] Wayland! Beware of!

[gentoo-user] Wayland! Beware of!

[Alan Mackenzie]

Hello, Gentoo.

I got a nasty shock earlier on this evening when I was updating my
(still newish) system.  Around (perhaps) 70 packages to be updated or
reloaded, several of them big packages.  What's going on?

There were lots of qt and kde packages being sucked in.  But what stood
out prominently was the wayland USE flag, which appeared to have been
enabled in most of these packages.

What on Earth is going on?  I never asked for wayland, and I haven't
received any news items about it in the last few weeks.  I know little
about this X substitute, but one thing's vitually certain; that
installing it as emerge intended would lead to a lot of breakage.

So I disabled the wayland USE flag in my make.conf, and the number of
packages to merge went down to 29.  I merged them.

I'm hoping my machine is still stable.  It would have been nice to have
got a news item about this change.  :-(

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: [gentoo-user] Wayland! Beware of!

[Eli Schwartz]

[-- Attachment #1.1: Type: text/plain, Size: 4046 bytes --]

On 9/23/24 4:14 PM, Alan Mackenzie wrote:
> Hello, Gentoo.
> 
> I got a nasty shock earlier on this evening when I was updating my
> (still newish) system.  Around (perhaps) 70 packages to be updated or
> reloaded, several of them big packages.  What's going on?
> 
> There were lots of qt and kde packages being sucked in.  But what stood
> out prominently was the wayland USE flag, which appeared to have been
> enabled in most of these packages.
> 
> What on Earth is going on?  I never asked for wayland, and I haven't
> received any news items about it in the last few weeks.  I know little
> about this X substitute, but one thing's vitually certain; that
> installing it as emerge intended would lead to a lot of breakage.


Intriguing that you feel it is "vitally certain" it will lead to
breakage. Where do you derive that conclusion from?

To be sure, installing it as emerge intended would lead to a lot of
recompiling and packages that you aren't using.

That's the description of bloat, not the description of breakage.

To be perfectly clear: both X and Wayland support can be and frequently
are compiled into the same program and/or the same toolkit. It kind of
needs to, because binary distros such as Arch, Debian, Fedora etc only
provide one build, and that has to work for people using X, and it has
to work for people using Wayland.

The resulting packages pull in support libraries that implement both
technologies. This is (usually, absent dlopen tricks) a fundamental
requirement of "ld.so", the runtime loader: if you compile support for
it, you have to have it installed.

But no code is *run*, because it is all conditional on a check that
looks like such:


#if defined(COMPILED_WITH_WAYLAND_SUPPORT)

if get_current_display_server_type() == 'wayland':
    run_wayland_specific_code()

#elif defined(COMPILED_WITH_X_SUPPORT)

if get_current_display_server_type() == 'xorg':
    run_xorg_specific_code()

#endif


Please note that no matter what display server you run,
get_current_display_server_type() is the same function either way, so
you're not actually running any "wayland code" even if you check to see
whether you are running wayland.


But you do need to install the wayland libraries, since the body of the
if statement runs "wayland code". Unless you compile the package with
USE="-wayland", which means that neither
get_current_display_server_type() nor run_wayland_specific_code() are
compiled at all.

In short, installing wayland will NOT break your X11 system and it is
rank paranoia to assume so or claim so.

But it will make you compile a bunch of stuff you don't want or need.
Surely, that is reason enough for you to make an informed choice about
disabling USE flags that you do not need, rather than worrying about how
Gentoo is broken all of a sudden?

Do you have that little faith in the Gentoo Developers, that you think
we'd make a USE flag change that made everyone's systems suddenly break?

:(


> So I disabled the wayland USE flag in my make.conf, and the number of
> packages to merge went down to 29.  I merged them.
> 
> I'm hoping my machine is still stable.  It would have been nice to have
> got a news item about this change.  :-(


Your machine was, is, and will continue to be stable. Please, relax. :)

News items are a better fit for scenarios where users are required to
take action. No one is required to take action here, though you may take
action if you wish. There are lots of other things that don't require
action, but you may choose to take action over. Any system update can
update a package that you like, to a new upstream version that removes
your favorite features. Does there need to be a news item every time a
package is updated?

I assure you you'd get quite sick and tired of the constant news items
if that actually happened.


P.S. Yes, I disabled the wayland USE as well. I'm not trying to push
wayland on you, don't worry.



-- 
Eli Schwartz


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 236 bytes --]

Re: [gentoo-user] Wayland! Beware of!

[Arsen Arsenović]

[-- Attachment #1: Type: text/plain, Size: 1334 bytes --]

Hello, Alan,

Alan Mackenzie <acm@muc.de> writes:

> Hello, Gentoo.
>
> I got a nasty shock earlier on this evening when I was updating my
> (still newish) system.  Around (perhaps) 70 packages to be updated or
> reloaded, several of them big packages.  What's going on?
>
> There were lots of qt and kde packages being sucked in.  But what stood
> out prominently was the wayland USE flag, which appeared to have been
> enabled in most of these packages.
>
> What on Earth is going on?  I never asked for wayland, and I haven't
> received any news items about it in the last few weeks.  I know little
> about this X substitute, but one thing's vitually certain; that
> installing it as emerge intended would lead to a lot of breakage.

That should not be the case.  If something breaks, that's a bug.

Wayland was added to the default USE of the desktop profiles because
most DE developers have started phasing out X11 support, or at least
treating it as second-class, and because enabling USE=wayland should
have no impact on those using the X session, as most/all Wayland support
is runtime-conditional.

So, that change agrees with developers of software we ship, while not
bringing our users much disadvantage.  Hence it was enabled.

Hope that helps, have a lovely evening.
-- 
Arsen Arsenović

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 381 bytes --]

Re: [gentoo-user] Wayland! Beware of!

[Wol]

On 23/09/2024 21:14, Alan Mackenzie wrote:
> What on Earth is going on?  I never asked for wayland, and I haven't
> received any news items about it in the last few weeks.  I know little
> about this X substitute, but one thing's vitually certain; that
> installing it as emerge intended would lead to a lot of breakage.

Well, everything is slowly moving to Wayland, or X13 as they didn't call 
it. And while I don't understand the details, X Org is basically dead.

X comes in two halves, the front end (or server, they use the words the 
other way round to normal), which is still maintained. And the back end, 
or client, that drives the hardware - this bit is basically abandonware 
apart from the Wayland compositor or whatever it is.

So put pretty simply, Wayland is fast becoming - if it isn't already - a 
hard dependency of X11. But if you want to run X11 as your sole 
windowing system, that's no problem, just run it over Wayland.

What makes you think that enabling Wayland will cause breakage? It 
shouldn't really do anything much, other than allowing apps to access 
Wayland features if they want. Given that both KDE/Plasma, and Gnome, 
are moving to Wayland (and pretty much hide Wayland from you, just like 
they hide X), I would have thought disabling Wayland was actually MORE 
likely to cause breakage.

Not that your hardware/X combo is going to bitrot, but the apps you rely 
on might start relying on Wayland and won't be happy if they can't find it.

(I'm cursing Plasma 6, but that's not Wayland's fault. afaict it's 
having problems importing/updating the old Plasma 5 settings with the 
result it resets itself every time I log in :-(

Cheers,
Wol

Re: [gentoo-user] Wayland! Beware of!

[Alan Mackenzie]

Hello, Eli.

On Mon, Sep 23, 2024 at 17:11:14 -0400, Eli Schwartz wrote:
> On 9/23/24 4:14 PM, Alan Mackenzie wrote:
> > Hello, Gentoo.

> > I got a nasty shock earlier on this evening when I was updating my
> > (still newish) system.  Around (perhaps) 70 packages to be updated or
> > reloaded, several of them big packages.  What's going on?

> > There were lots of qt and kde packages being sucked in.  But what stood
> > out prominently was the wayland USE flag, which appeared to have been
> > enabled in most of these packages.

> > What on Earth is going on?  I never asked for wayland, and I haven't
> > received any news items about it in the last few weeks.  I know little
> > about this X substitute, but one thing's vitually certain; that
> > installing it as emerge intended would lead to a lot of breakage.


> Intriguing that you feel it is "vitally certain" it will lead to
> breakage. Where do you derive that conclusion from?

It's a big change, wayland is known to be incompatible with X, as far as
I'm aware XFCE doesn't yet work with it, and there is no completely
satisfactory version of Emacs which runs with wayland (I'm an Emacs
developer, and bugs keep coming in from people trying Emacs on wayland.)

> To be sure, installing it as emerge intended would lead to a lot of
> recompiling and packages that you aren't using.

Yes.

> That's the description of bloat, not the description of breakage.

Maybe so, but who wants bloat?  There are binary distribution for such
people.  ;-)

> To be perfectly clear: both X and Wayland support can be and frequently
> are compiled into the same program and/or the same toolkit. It kind of
> needs to, because binary distros such as Arch, Debian, Fedora etc only
> provide one build, and that has to work for people using X, and it has
> to work for people using Wayland.

OK, thanks.  I didn't know that.

> The resulting packages pull in support libraries that implement both
> technologies. This is (usually, absent dlopen tricks) a fundamental
> requirement of "ld.so", the runtime loader: if you compile support for
> it, you have to have it installed.

> But no code is *run*, because it is all conditional on a check that
> looks like such:


> #if defined(COMPILED_WITH_WAYLAND_SUPPORT)

> if get_current_display_server_type() == 'wayland':
>     run_wayland_specific_code()

> #elif defined(COMPILED_WITH_X_SUPPORT)

> if get_current_display_server_type() == 'xorg':
>     run_xorg_specific_code()

> #endif

OK.

> Please note that no matter what display server you run,
> get_current_display_server_type() is the same function either way, so
> you're not actually running any "wayland code" even if you check to see
> whether you are running wayland.

But the unused code still gets built in, doesn't it?  That's a somewhat
un-gentoo like situation.

> But you do need to install the wayland libraries, since the body of the
> if statement runs "wayland code". Unless you compile the package with
> USE="-wayland", which means that neither
> get_current_display_server_type() nor run_wayland_specific_code() are
> compiled at all.

That's what I ended up doing.

> In short, installing wayland will NOT break your X11 system and it is
> rank paranoia to assume so or claim so.

Put yourself in my position, which wasn't one of knowledge.  It's a
matter of decades of experience which suggest that big changes cause
breakage, just like throwing crockery onto the floor does.

> But it will make you compile a bunch of stuff you don't want or need.
> Surely, that is reason enough for you to make an informed choice about
> disabling USE flags that you do not need, rather than worrying about how
> Gentoo is broken all of a sudden?

That was kind of the point I was making.  I had to guess which flag to
disable; I don't think it was in any documentation.

> Do you have that little faith in the Gentoo Developers, that you think
> we'd make a USE flag change that made everyone's systems suddenly break?

It happens, from time to time, by accident.  For example, emerge
--depclean on my system wants to unmerge openrc.  Not a deliberate move
by the developers, just some accident.  But it's the reason I don't do
emerge --depclean, ever.

> :(


> > So I disabled the wayland USE flag in my make.conf, and the number of
> > packages to merge went down to 29.  I merged them.

> > I'm hoping my machine is still stable.  It would have been nice to have
> > got a news item about this change.  :-(


> Your machine was, is, and will continue to be stable. Please, relax. :)

Thanks!

> News items are a better fit for scenarios where users are required to
> take action. No one is required to take action here, though you may take
> action if you wish. There are lots of other things that don't require
> action, but you may choose to take action over. Any system update can
> update a package that you like, to a new upstream version that removes
> your favorite features. Does there need to be a news item every time a
> package is updated?

> I assure you you'd get quite sick and tired of the constant news items
> if that actually happened.

OK, but this change appears to be dramatic, and likely to cause concern
to users.  Most changes are much smaller, and can be emerged without
thought.  But for something like switching on a contraversial package
like wayland, something which on my system would have caused lots of qt
and kde packages to be loaded (why?), a warning might not have gone
amiss.

> P.S. Yes, I disabled the wayland USE as well. I'm not trying to push
> wayland on you, don't worry.

:-)

> -- 
> Eli Schwartz

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: [gentoo-user] Wayland! Beware of!

[karl]

Wol:
...
> X comes in two halves, the front end (or server, they use the words the 
> other way round to normal),
...

No, server is a software concept, a program that waits and responds to 
inbound calls, the X-server is just that. A client is a program/user
that pokes at the server and get responses.

It's just the pc hoard that thinks a server is some machine handling
databases, mail, files, printers or whatever.

It has noting to do with what is there or here.

Regards,
/Karl Hammar

Re: [gentoo-user] Wayland! Beware of!

[Eli Schwartz]

[-- Attachment #1.1: Type: text/plain, Size: 2564 bytes --]

On 9/23/24 6:08 PM, Alan Mackenzie wrote:
>> Do you have that little faith in the Gentoo Developers, that you think
>> we'd make a USE flag change that made everyone's systems suddenly break?
> 
> It happens, from time to time, by accident.  For example, emerge
> --depclean on my system wants to unmerge openrc.  Not a deliberate move
> by the developers, just some accident.  But it's the reason I don't do
> emerge --depclean, ever.


This should not generally be possible. The @system set contains
virtual/service-manager, so you cannot depclean that.

$ emerge -pvc systemd

Calculating dependencies... done!
  sys-apps/systemd-255.11 pulled in by:
[...]
    virtual/service-manager-1-r2 requires sys-apps/systemd
[...]

$ emerge -pvc virtual/service-manager

Calculating dependencies... done!
  virtual/service-manager-1-r2 pulled in by:
    @system requires virtual/service-manager




And this works the same in an openrc chroot as well!

# emerge -pvc virtual/service-manager

Calculating dependencies... done!
  virtual/service-manager-1-r2 pulled in by:
    @system requires virtual/service-manager

# emerge -pvc openrc

Calculating dependencies... done!
  sys-apps/openrc-0.54.2 pulled in by:
    net-misc/netifrc-0.7.8-r1 requires >=sys-apps/openrc-0.15
    virtual/service-manager-1-r2 requires sys-apps/openrc





It does that using an "any-of" dependency:

# cat /var/db/pkg/virtual/service-manager-1-r2/RDEPEND
|| ( sys-apps/openrc sys-apps/openrc-navi sys-apps/s6-rc
sys-apps/systemd sys-process/runit virtual/daemontools )


So, @system requires you to have any one of:

- openrc
- openrc-navi (a testing fork with openrc user services)
- s6
- systemd
- runit
- daemontools


It's possible you have installed another one of these packages too. If
you do, then virtual/service-manager will still be satisfied, and it
will allow you to depclean openrc.


In theory, one should not have multiple init systems installed. And
openrc is the preferred satisfier, so if you use `emerge --depclean` it
will try to depclean the other package, not openrc. But you can depclean
openrc itself in that case, since portage doesn't know which init system
you intend to keep.

Even in this case it emits a warning:

!!! 'sys-apps/openrc' (virtual/service-manager) is part of your system
profile.
!!! Unmerging it may be damaging to your system.


to make sure you are fully aware that you intend to depclean a package
that *might* be the wrong one.


-- 
Eli Schwartz


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 236 bytes --]

Re: [gentoo-user] Wayland! Beware of!

[Michael Orlitzky]

On Mon, 2024-09-23 at 22:08 +0000, Alan Mackenzie wrote:
> 
> But the unused code still gets built in, doesn't it?  That's a somewhat
> un-gentoo like situation.
> 

It depends on the language, but in a compiled language, not usually.
Regardless: if you aren't a fan of widespread changes to global USE
flags based on what's fashionable at the time, you're gonna have a bad
time in the desktop profile. Run "eselect profile list" and pick one
that's higher up the tree.

Re: [gentoo-user] Wayland! Beware of!

[Mitchell Dorrell]

On Mon, Sep 23, 2024 at 5:11 PM Eli Schwartz <eschwartz@gentoo.org> wrote:
> The resulting packages pull in support libraries that implement both
> technologies. This is (usually, absent dlopen tricks) a fundamental
> requirement of "ld.so", the runtime loader: if you compile support for
> it, you have to have it installed.

I run a lean X system for desktop workflows, with USE="-wayland".
Every unconditional dev-libs/wayland dependency I've encountered has
used dlopen. These were proprietary binary applications like Zoom and
Slack. On an X system, they work completely fine without
dev-libs/wayland, though. If I remember correctly, the word was,
"Upstream says it's a dependency, so it's a dependency.".

The moral of that story is, an unconditional dependency on Wayland
*does not mean* that it isn't fully functional without
dev-libs/wayland.

On Mon, Sep 23, 2024 at 5:20 PM Wol <antlists@youngman.org.uk> wrote:
> So put pretty simply, Wayland is fast becoming - if it isn't already - a
> hard dependency of X11. But if you want to run X11 as your sole
> windowing system, that's no problem, just run it over Wayland.

I run a four-monitor system using NVIDIA's closed-source drivers. Last
I heard, Wayland did not work with such a combination. Has that
changed?

-MD

Re: [gentoo-user] Wayland! Beware of!

[Matt Jolly]

On 24/9/24 10:52, Mitchell Dorrell wrote:

> I run a four-monitor system using NVIDIA's closed-source drivers. Last
> I heard, Wayland did not work with such a combination. Has that
> changed?

I run several 3-monitor NVIDIA setups on Wayland with no issue.

One of my 4-monitor setups has one screen plugged into
an intel iGPU port, so I can't say for sure that 4 plugged
into a single Nvidia card work, however I can say that
driving 4 screens total (or 3x2k@144Hz) isn't a problem
for devolopment and even gaming if the hardware is otherwise
capable.

Give it a try, you may be pleasantly surprised by what you discover.

I would go with 555 or 560 drivers for the Explicit Sync
support though - I found that it made my xwayland experience
(on Plasma...) significantly better.

Cheers,

Matt.

Re: [gentoo-user] Wayland! Beware of!

[Eli Schwartz]

[-- Attachment #1.1: Type: text/plain, Size: 2697 bytes --]

On 9/23/24 8:52 PM, Mitchell Dorrell wrote:
> I run a lean X system for desktop workflows, with USE="-wayland".
> Every unconditional dev-libs/wayland dependency I've encountered has
> used dlopen. These were proprietary binary applications like Zoom and
> Slack. On an X system, they work completely fine without
> dev-libs/wayland, though. If I remember correctly, the word was,
> "Upstream says it's a dependency, so it's a dependency.".
> 
> The moral of that story is, an unconditional dependency on Wayland
> *does not mean* that it isn't fully functional without
> dev-libs/wayland.


I took a look at Gentoo's net-im/zoom package as an example.

It has USE=wayland. If you disable wayland support, it deletes:

- /opt/zoom/cef/libGLESv2.so

conditional on the bundled Qt:

- /opt/zoom/Qt/lib/libQt5Wayland*.so*
- /opt/zoom/Qt/plugins/wayland*
- /opt/zoom/Qt/plugins/platforms/libqwayland*.so
- /opt/zoom/Qt/qml/QtWayland


including comments such as "Soname dependency on libwayland-client.so.0"
(for libGLESv2, which doesn't actually seem to be accurate?)


I did say "usually" for a reason. Proprietary software has a dual habit of:
- statically linking to support libraries such as say, libwayland-client
- going to extremes to defer loading libraries which they don't bundle,
  behind dlopen conditionals to make it more likely it will run on
  diverse end user systems


This is typically just not the case for open source software, because
they can rely on package manager distribution with enforced
dependencies, and people rebuilding from source if they don't want a
specific dependency.

And of course: compiling against libwayland-client and hiding it behind
a dlopen still requires you to have what to compile against as a build
dependency, making it less attractive to people that know the software
can simply be recompiled from source.

slack does indeed have only one dependency on dev-libs/wayland that I
can find -- it comes from
https://swiftshader.googlesource.com/SwiftShader/+/a88d056919f1a84777c8b33531f40acc74a19d1e%5E%21/

Previously, slack was modified to have an unconditional RDEPEND on
wayland via
https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=0328dbab456f04c57b286cf93235f7323c7c5a0f

The commit message indicates exactly why it was added and it was not
"upstream says it's a dependency, so it's a dependency". :) Please open
a bug report for it. Thanks.

...

Overall I think that these phantom wayland dependencies are an artifact
of Electron's constant churn and the fact that every application using
electron basically bundles its own inconsistent copy of it.


-- 
Eli Schwartz


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 236 bytes --]

Re: [gentoo-user] Wayland! Beware of!

[Wols Lists]

On 23/09/2024 23:53, karl@aspodata.se wrote:
> It's just the pc hoard that thinks a server is some machine handling
> databases, mail, files, printers or what

In other words, X uses the words the other way round than most people - 
what I said.

Doesn't mean the majority are right! As far as I'm aware X got there 
first, but is now swimming against the tide.

Cheers,
Wol

Re: [gentoo-user] Wayland! Beware of!

[Mitchell Dorrell]

On Mon, Sep 23, 2024 at 9:13 PM Matt Jolly <kangie@gentoo.org> wrote:
> On 24/9/24 10:52, Mitchell Dorrell wrote:
>
> > I run a four-monitor system using NVIDIA's closed-source drivers. Last
> > I heard, Wayland did not work with such a combination. Has that
> > changed?
>
> I run several 3-monitor NVIDIA setups on Wayland with no issue.
...
> Give it a try, you may be pleasantly surprised by what you discover.

Do you specifically use the closed-source drivers, though?

On Mon, Sep 23, 2024 at 9:52 PM Eli Schwartz <eschwartz@gentoo.org> wrote:
> I did say "usually" for a reason.

Yes, of course. I was only trying to say that using dlopen for a
wayland dependency isn't necessarily rare, and that some ebuilds code
this as an unconditional dependency.

> slack does indeed have only one dependency on dev-libs/wayland that I
> can find -- it comes from
> https://swiftshader.googlesource.com/SwiftShader/+/a88d056919f1a84777c8b33531f40acc74a19d1e%5E%21/
>
> Previously, slack was modified to have an unconditional RDEPEND on
> wayland via
> https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=0328dbab456f04c57b286cf93235f7323c7c5a0f
>
> The commit message indicates exactly why it was added and it was not
> "upstream says it's a dependency, so it's a dependency". :) Please open
> a bug report for it. Thanks.

Yep, I'll submit a bug report for Slack when I get a chance. Think I
should also submit one for Zoom, since libGLESv2 doesn't link to it
anymore?

> Overall I think that these phantom wayland dependencies are an artifact
> of Electron's constant churn and the fact that every application using
> electron basically bundles its own inconsistent copy of it.

I agree. There's only one other non-CEF/non-Electron application where
I also noticed an unnecessary Wayland dependency. I should submit a
bug report for that, too.

> --
> Eli Schwartz
>

Re: [gentoo-user] Wayland! Beware of!

[Dr Rainer Woitok]

Alan,

On Mon, 23 Sep 2024 22:08:56 +0000 you wrote:

> ...
>                                              For example, emerge
> --depclean on my system wants to unmerge openrc.  Not a deliberate move
> by the developers, just some accident.  But it's the reason I don't do
> emerge --depclean, ever.

No, that's not some accident.   As Eli already pointed out this can only
happen,  if you have at least  one more dependency  of package "virtual/
service-manager" installed.  And if really no package on your system re-
quires package "sys-apps/openrc" but YOU want that package,  YOU are the
instance which must require it by simply adding it to "@world".

Not ever running "emerge --depclean" may have the tendency of collecting
bloat packages  on your rig,  packages you neither need nor want.   So I
would suggest running  "emerge --ask --depclean"  on a regular basis and
thoroughly checking the output before answering "yes".

Sincerely,
  Rainer

[gentoo-user] --depclean and openrc [Was: Wayland! Beware of!]

[Alan Mackenzie]

Hello, Eli.

On Mon, Sep 23, 2024 at 18:54:50 -0400, Eli Schwartz wrote:
> On 9/23/24 6:08 PM, Alan Mackenzie wrote:
> >> Do you have that little faith in the Gentoo Developers, that you think
> >> we'd make a USE flag change that made everyone's systems suddenly break?

> > It happens, from time to time, by accident.  For example, emerge
> > --depclean on my system wants to unmerge openrc.  Not a deliberate
> > move by the developers, just some accident.  But it's the reason I
> > don't do emerge --depclean, ever.

> This should not generally be possible. The @system set contains
> virtual/service-manager, so you cannot depclean that.

It is very much possible, and it happens.  The mechanism is understood,
you've outlined it below.

[ .... ]

> So, @system requires you to have any one of:

> - openrc
> - openrc-navi (a testing fork with openrc user services)
> - s6
> - systemd
> - runit
> - daemontools

> It's possible you have installed another one of these packages too. If
> you do, then virtual/service-manager will still be satisfied, and it
> will allow you to depclean openrc.

Yes, I have daemontools, needed as a component of a qmail variant.

> In theory, one should not have multiple init systems installed. And
> openrc is the preferred satisfier, so if you use `emerge --depclean` it
> will try to depclean the other package, not openrc. But you can depclean
> openrc itself in that case, since portage doesn't know which init system
> you intend to keep.

If I had invoked --depclean without the -a (or -p) flag, my system would
have had openrc removed, and it would have been unbootable.  This is the
sort of thing a new Gentoo user might do.

> Even in this case it emits a warning:

> !!! 'sys-apps/openrc' (virtual/service-manager) is part of your system
> profile.
> !!! Unmerging it may be damaging to your system.

So, having your system made unbootable is opt-out rather than opt-in.

> to make sure you are fully aware that you intend to depclean a package
> that *might* be the wrong one.

The context of this discussion was an implication that the Gentoo
maintainers wouldn't make a change "that made everyone's systems suddenly
break".  I submitted a bug report about --depclean back in the summer of
2021 (though I can't find that bug any more).  I think it was closed as
not-a-bug.

There are several ways this could have been fixed, for example with
--depclean preserving packages in system, as well as world.  But it was
regarded as not a bug.

So I think it is fair to say that the Gentoo developers are content for
some systems (in particular, mine) suddenly to break.  I am thus somewhat
sceptical about things in Gentoo which may be based on assumptions which
don't hold in my system.  The new +wayland USE flag kind of looked a bit
like that to me.  Actually, it wasn't, so I apologise for my opening
post.

> -- 
> Eli Schwartz

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: [gentoo-user] --depclean and openrc [Was: Wayland! Beware of!]

[Arsen Arsenović]

[-- Attachment #1: Type: text/plain, Size: 3557 bytes --]

Alan Mackenzie <acm@muc.de> writes:

> Hello, Eli.
>
> On Mon, Sep 23, 2024 at 18:54:50 -0400, Eli Schwartz wrote:
>> On 9/23/24 6:08 PM, Alan Mackenzie wrote:
>> >> Do you have that little faith in the Gentoo Developers, that you think
>> >> we'd make a USE flag change that made everyone's systems suddenly break?
>
>> > It happens, from time to time, by accident.  For example, emerge
>> > --depclean on my system wants to unmerge openrc.  Not a deliberate
>> > move by the developers, just some accident.  But it's the reason I
>> > don't do emerge --depclean, ever.
>
>> This should not generally be possible. The @system set contains
>> virtual/service-manager, so you cannot depclean that.
>
> It is very much possible, and it happens.  The mechanism is understood,
> you've outlined it below.
>
> [ .... ]
>
>> So, @system requires you to have any one of:
>
>> - openrc
>> - openrc-navi (a testing fork with openrc user services)
>> - s6
>> - systemd
>> - runit
>> - daemontools
>
>> It's possible you have installed another one of these packages too. If
>> you do, then virtual/service-manager will still be satisfied, and it
>> will allow you to depclean openrc.
>
> Yes, I have daemontools, needed as a component of a qmail variant.

In that case, it'd be wise to 'emerge -n openrc' to prevent such
trouble.

I do wonder if we should keep s6, runit and daemontools in that virutal
though, given that we can't boot them.  Perhaps they'd be fine behind a
USE flag.  I'll propose that.

>> In theory, one should not have multiple init systems installed. And
>> openrc is the preferred satisfier, so if you use `emerge --depclean` it
>> will try to depclean the other package, not openrc. But you can depclean
>> openrc itself in that case, since portage doesn't know which init system
>> you intend to keep.
>
> If I had invoked --depclean without the -a (or -p) flag, my system
> would have had openrc removed, and it would have been unbootable.
> This is the sort of thing a new Gentoo user might do.
>
>> Even in this case it emits a warning:
>
>> !!! 'sys-apps/openrc' (virtual/service-manager) is part of your system
>> profile.
>> !!! Unmerging it may be damaging to your system.
>
> So, having your system made unbootable is opt-out rather than opt-in.
>
>> to make sure you are fully aware that you intend to depclean a package
>> that *might* be the wrong one.
>
> The context of this discussion was an implication that the Gentoo
> maintainers wouldn't make a change "that made everyone's systems
> suddenly break".  I submitted a bug report about --depclean back in
> the summer of 2021 (though I can't find that bug any more).  I think
> it was closed as not-a-bug.

Whoever closed it was wrong, frankly.

> There are several ways this could have been fixed, for example with
> --depclean preserving packages in system, as well as world.

That probably would not fix anything here, openrc is not in @system,
virtual/service-manager is.

> But it was regarded as not a bug.
>
> So I think it is fair to say that the Gentoo developers are content for
> some systems (in particular, mine) suddenly to break.

Developers differ a good bit.. we generally try not to break things.

> I am thus somewhat sceptical about things in Gentoo which may be based
> on assumptions which don't hold in my system.  The new +wayland USE
> flag kind of looked a bit like that to me.  Actually, it wasn't, so I
> apologise for my opening post.
-- 
Arsen Arsenović

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 381 bytes --]

Re: [gentoo-user] --depclean and openrc

[Alan Mackenzie]

Hello, Arsen.

On Tue, Sep 24, 2024 at 13:40:57 +0200, Arsen Arsenović wrote:
> Alan Mackenzie <acm@muc.de> writes:

[ .... ]

> >> So, @system requires you to have any one of:

> >> - openrc
> >> - openrc-navi (a testing fork with openrc user services)
> >> - s6
> >> - systemd
> >> - runit
> >> - daemontools

> >> It's possible you have installed another one of these packages too. If
> >> you do, then virtual/service-manager will still be satisfied, and it
> >> will allow you to depclean openrc.

> > Yes, I have daemontools, needed as a component of a qmail variant.

> In that case, it'd be wise to 'emerge -n openrc' to prevent such
> trouble.

Yes.

> I do wonder if we should keep s6, runit and daemontools in that virutal
> though, given that we can't boot them.  Perhaps they'd be fine behind a
> USE flag.  I'll propose that.

Thanks!

[ .... ]

> > The context of this discussion was an implication that the Gentoo
> > maintainers wouldn't make a change "that made everyone's systems
> > suddenly break".  I submitted a bug report about --depclean back in
> > the summer of 2021 (though I can't find that bug any more).  I think
> > it was closed as not-a-bug.

> Whoever closed it was wrong, frankly.

I've found the bug.  It was 803878.  The developer who responded treated
my bug as though it were a request for personal support, and he
completely evaded my point that it was a bug in portage which should be
fixed.  It was actually closed as TEST-REQUEST, whatever that means.  The
bug was never addressed.

> > There are several ways this could have been fixed, for example with
> > --depclean preserving packages in system, as well as world.

> That probably would not fix anything here, openrc is not in @system,
> virtual/service-manager is.

--depclean could preserve anything under a virtual in @system.

> > But it was regarded as not a bug.

> > So I think it is fair to say that the Gentoo developers are content for
> > some systems (in particular, mine) suddenly to break.

> Developers differ a good bit.. we generally try not to break things.

:-)

> > I am thus somewhat sceptical about things in Gentoo which may be based
> > on assumptions which don't hold in my system.  The new +wayland USE
> > flag kind of looked a bit like that to me.  Actually, it wasn't, so I
> > apologise for my opening post.
> -- 
> Arsen Arsenović

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: [gentoo-user] --depclean and openrc [Was: Wayland! Beware of!]

[Eli Schwartz]

[-- Attachment #1.1: Type: text/plain, Size: 6871 bytes --]

On 9/24/24 7:30 AM, Alan Mackenzie wrote:
>> This should not generally be possible. The @system set contains
>> virtual/service-manager, so you cannot depclean that.
> 
> It is very much possible, and it happens.  The mechanism is understood,
> you've outlined it below.


Clearly, since I said it is "generally" not possible, I agree that it is
sometimes possible and the mechanism for the sometimes is understood.

After all, I did outline it, and you agree with my outline.

So why, exactly, are you *arguing* with me, as though you believe I have
said it is not possible?

Can you point me to where I said it is not possible?

I said it's an edge case, not a systematic flaw in Gentoo or portage
designed to break people's systems. Edge cases should be reported and
fixed, but also edge cases have trivial workarounds which you can carry
out: add openrc manually to @world, and it is no longer dangerous to run
--depclean as part of regular maintenance of a healthy system.


>> It's possible you have installed another one of these packages too. If
>> you do, then virtual/service-manager will still be satisfied, and it
>> will allow you to depclean openrc.
> 
> Yes, I have daemontools, needed as a component of a qmail variant.


Sigh, djbware strikes again. The fact that daemontools claims to be a
service manager, but is needed for random packages WITHOUT being used as
a service manager, is alarming and probably broken.


>> In theory, one should not have multiple init systems installed. And
>> openrc is the preferred satisfier, so if you use `emerge --depclean` it
>> will try to depclean the other package, not openrc. But you can depclean
>> openrc itself in that case, since portage doesn't know which init system
>> you intend to keep.
> 
> If I had invoked --depclean without the -a (or -p) flag, my system would
> have had openrc removed, and it would have been unbootable.  This is the
> sort of thing a new Gentoo user might do.
> 
>> Even in this case it emits a warning:
> 
>> !!! 'sys-apps/openrc' (virtual/service-manager) is part of your system
>> profile.
>> !!! Unmerging it may be damaging to your system.
> 
> So, having your system made unbootable is opt-out rather than opt-in.


That is a severely unkind interpretation of what I said, and of what
portage does.

Also, installing daemontools isn't the kind of thing a new Gentoo user
might do. Nor is installing qmail.


>> to make sure you are fully aware that you intend to depclean a package
>> that *might* be the wrong one.
> 
> The context of this discussion was an implication that the Gentoo
> maintainers wouldn't make a change "that made everyone's systems suddenly
> break".  I submitted a bug report about --depclean back in the summer of
> 2021 (though I can't find that bug any more).  I think it was closed as
> not-a-bug.
> 
> There are several ways this could have been fixed, for example with
> --depclean preserving packages in system, as well as world.  But it was
> regarded as not a bug.
> 
> So I think it is fair to say that the Gentoo developers are content for
> some systems (in particular, mine) suddenly to break.  I am thus somewhat
> sceptical about things in Gentoo which may be based on assumptions which
> don't hold in my system.  The new +wayland USE flag kind of looked a bit
> like that to me.  Actually, it wasn't, so I apologise for my opening
> post.


There is nothing sudden about this! No change has been made! According
to your explanation, the presence of daemontools on a system has always
made --depclean result in potentially making a system unbootable.

The Gentoo developers have taken no action to *make* this a problem. It
is the unfortunate combination of a number of moving parts that together
result in a historically present issue.

Inferring from here that Gentoo developers making an active profile
change with the intent of resulting in systems suddenly breaking while
dismissing concerns, is unreasonable, irrational, and paranoid. Sorry.

Gentoo works better when users report issues and ask for them to be fixed.

Gentoo works better when users see a change and ask what the
ramifications are, e.g. "I was curious whether this would have a
negative effect on my X-only system", rather than immediately leaping to
"PSA!!! DANGER ALERT! CODE RED, ALL GENTOO USERS BEWARE!!!"

You can always post the "PSA!!! DANGER ALERT! CODE RED" if you asked for
information and did not get an answer that satisfied you, but the
initial assumption of good faith would be appreciated.


....


Regarding the daemontools situation:

"""
for example with --depclean preserving packages in system, as well as world
"""

Is not a valid suggestion, since --depclean already does precisely this,
but openrc isn't a package in system, it is a package that satisfies a
recursive dependency of system. As far as portage knows, it is already
doing exactly what you want it to do, as described in the Package
Manager Specification.

Perhaps you meant to say that --depclean should preserve all versions of
an "any-of" dependency. This would break a whole lot of use cases, as
then one would no longer be able to change their system to suit
themselves using the intended power of virtuals.

For example, it would become impossible for a user to install s6-rc into
their world file, with the intention of using s6-rc as their service
manager, and then --depclean and remove openrc which they no longer
intend to use!

(It would also be impossible to install vim or emacs, then uninstall
nano. For that matter, it would be impossible for an emacs user to
install vim, try it out for a day, decide they don't like it, and
uninstall vim. Vim would be there to stay: forever.)

Normally, installing s6-rc is an intentional action to use s6-rc. But
apparently, "normally" installing daemontools isn't an intentional
action to use daemontools.

Thus, reporting this as a bug against portage is illogical, but
reporting it as a bug against virtual/service-manager is logical. I can
understand why a bug submitted "about --depclean" would be closed as
not-a-bug, since it is... not, in fact, a bug, there is a totally
different bug.

Perhaps the person who closed that bug should have thought deeper about
the implications of such a thing, and reassigned that bug to the correct
package with a fixed explanation. And perhaps you should have
communicated better why it's a problem for you to install daemontools
*without intending to* and having that affect openrc. For example, by
highlighting that daemontools isn't being used as a service manager and
you do not believe installing "ordinary applications such as qmail"
should be allowed to override your choice of init system.


-- 
Eli Schwartz


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 236 bytes --]

Re: [gentoo-user] --depclean and openrc

[Eli Schwartz]

[-- Attachment #1.1: Type: text/plain, Size: 1161 bytes --]

On 9/24/24 8:34 AM, Alan Mackenzie wrote:
>>> The context of this discussion was an implication that the Gentoo
>>> maintainers wouldn't make a change "that made everyone's systems
>>> suddenly break".  I submitted a bug report about --depclean back in
>>> the summer of 2021 (though I can't find that bug any more).  I think
>>> it was closed as not-a-bug.
> 
>> Whoever closed it was wrong, frankly.
> 
> I've found the bug.  It was 803878.  The developer who responded treated
> my bug as though it were a request for personal support, and he
> completely evaded my point that it was a bug in portage which should be
> fixed.  It was actually closed as TEST-REQUEST, whatever that means.  The
> bug was never addressed.


The bug was confused about the issue at hand and lacking the full
explanation of why it's an issue it could be understood why it was
assumed to be a personal support request.

It is not a bug in portage, which is part of the confusion here. It is a
bug in virtual/service-manager.

I reopened the bug report, corrected the description, and assigned it.

https://bugs.gentoo.org/803878


-- 
Eli Schwartz


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 236 bytes --]

Re: [gentoo-user] --depclean and openrc

[Alan Mackenzie]

Hello, Eli.

On Tue, Sep 24, 2024 at 11:24:14 -0400, Eli Schwartz wrote:
> On 9/24/24 8:34 AM, Alan Mackenzie wrote:
> >>> The context of this discussion was an implication that the Gentoo
> >>> maintainers wouldn't make a change "that made everyone's systems
> >>> suddenly break".  I submitted a bug report about --depclean back in
> >>> the summer of 2021 (though I can't find that bug any more).  I think
> >>> it was closed as not-a-bug.

> >> Whoever closed it was wrong, frankly.

> > I've found the bug.  It was 803878.  The developer who responded treated
> > my bug as though it were a request for personal support, and he
> > completely evaded my point that it was a bug in portage which should be
> > fixed.  It was actually closed as TEST-REQUEST, whatever that means.  The
> > bug was never addressed.


> The bug was confused about the issue at hand and lacking the full
> explanation of why it's an issue it could be understood why it was
> assumed to be a personal support request.

Whenever I get a confused bug report, the first thing I do is work out
what the problem really is, which often involves getting in touch with
the OP.  That didn't happen with 803878  - the response to my initial
bug report occurred with 17 minutes of it being raised.   

> It is not a bug in portage, which is part of the confusion here. It is a
> bug in virtual/service-manager.

That is clear now, it wasn't clear in 2021-06 when the bug was raised.
It is surely not the submitter's job to work out where in a system a bug
is caused, rather it's the job of the specialist handling the bug.

> I reopened the bug report, corrected the description, and assigned it.

Thanks!  That's appreciated.  It's looking like it's now going to get
fixed.  :-)

> https://bugs.gentoo.org/803878


> -- 
> Eli Schwartz

-- 
Alan Mackenzie (Nuremberg, Germany).

What is what (Re: [gentoo-user] Wayland! Beware of!)

[karl]

Wol:
> On 23/09/2024 23:53, karl@aspodata.se wrote:
> > It's just the pc hoard that thinks a server is some machine handling
(that should be horde, not hoard even though it sounds funny...)
> > databases, mail, files, printers or what
> 
> In other words, X uses the words the other way round than most people - 
> what I said.
> 
> Doesn't mean the majority are right! As far as I'm aware X got there 
> first, but is now swimming against the tide.

It could be a case of one million flies cannot be wrong, shit is good..
but at the same time what people call a server is a machine running 
server programs, but the server itself is the program running.
Without that program it is just a fancy box, I could use the very same
box and use it as a desktop, and there is another false dicotomy, that
there are desktops and servers, but the majority of all computers out
ther are embedded. And many persons called (prior to laptops) the
box a disk.

So should computer words be defined by non-professionals or thoose
who knows ?

One effect of letting non-professionals define words is the case when
the poeple handling the collection of television licences had the 
opinion the a computer is a television set and hence people with a
computer should pay for the right to view television.

So please stop spread misconcetions, or you might say, turn back the tide.

Regards,
/Karl Hammar

Re: [gentoo-user] --depclean and openrc [Was: Wayland! Beware of!]

[Alan Mackenzie]

Hello, Eli.

On Tue, Sep 24, 2024 at 11:15:10 -0400, Eli Schwartz wrote:
> On 9/24/24 7:30 AM, Alan Mackenzie wrote:

[ .... ]

> >> It's possible you have installed another one of these packages too. If
> >> you do, then virtual/service-manager will still be satisfied, and it
> >> will allow you to depclean openrc.

> > Yes, I have daemontools, needed as a component of a qmail variant.

> Sigh, djbware strikes again. The fact that daemontools claims to be a
> service manager, but is needed for random packages WITHOUT being used as
> a service manager, is alarming and probably broken.

Yes, we agree on this.

> >> In theory, one should not have multiple init systems installed. And
> >> openrc is the preferred satisfier, so if you use `emerge --depclean` it
> >> will try to depclean the other package, not openrc. But you can depclean
> >> openrc itself in that case, since portage doesn't know which init system
> >> you intend to keep.

> > If I had invoked --depclean without the -a (or -p) flag, my system would
> > have had openrc removed, and it would have been unbootable.  This is the
> > sort of thing a new Gentoo user might do.

> >> Even in this case it emits a warning:

> >> !!! 'sys-apps/openrc' (virtual/service-manager) is part of your system
> >> profile.
> >> !!! Unmerging it may be damaging to your system.

> > So, having your system made unbootable is opt-out rather than opt-in.


> That is a severely unkind interpretation of what I said, and of what
> portage does.

I don't think somebody whose system would no longer boot would agree with
you there.

> Also, installing daemontools isn't the kind of thing a new Gentoo user
> might do. Nor is installing qmail.

I don't see why not.  I was new to Gentoo (but knew qmail) when I first
installed it on Gentoo.

> >> to make sure you are fully aware that you intend to depclean a package
> >> that *might* be the wrong one.

> > The context of this discussion was an implication that the Gentoo
> > maintainers wouldn't make a change "that made everyone's systems suddenly
> > break".  I submitted a bug report about --depclean back in the summer of
> > 2021 (though I can't find that bug any more).  I think it was closed as
> > not-a-bug.

> > There are several ways this could have been fixed, for example with
> > --depclean preserving packages in system, as well as world.  But it was
> > regarded as not a bug.

> > So I think it is fair to say that the Gentoo developers are content for
> > some systems (in particular, mine) suddenly to break.  I am thus somewhat
> > sceptical about things in Gentoo which may be based on assumptions which
> > don't hold in my system.  The new +wayland USE flag kind of looked a bit
> > like that to me.  Actually, it wasn't, so I apologise for my opening
> > post.


> There is nothing sudden about this! No change has been made! According
> to your explanation, the presence of daemontools on a system has always
> made --depclean result in potentially making a system unbootable.

> The Gentoo developers have taken no action to *make* this a problem. It
> is the unfortunate combination of a number of moving parts that together
> result in a historically present issue.

> Inferring from here that Gentoo developers making an active profile
> change with the intent of resulting in systems suddenly breaking while
> dismissing concerns, is unreasonable, irrational, and paranoid. Sorry.

Please note that when I raised the matter, I first described it as
accidental, and I've never meant to imply it was anything else.  The
"content for some systems ... to break" was a direct reference to bug
803878 being summarily rejected in 2021.

Anyhow, I think all misunderstandings with respect to that bug have now
been resolved, and it is getting fixed.

> Gentoo works better when users report issues and ask for them to be fixed.

As I did with bug 803878.

> Gentoo works better when users see a change and ask what the
> ramifications are, e.g. "I was curious whether this would have a
> negative effect on my X-only system", rather than immediately leaping to
> "PSA!!! DANGER ALERT! CODE RED, ALL GENTOO USERS BEWARE!!!"

Perhaps.  As already said, I would have been much less jumpy if the
explanations which have come in this thread had been in a news item.

With this change involving wayland, users HAVE to make a decision, namely
whether to set USE='-wayland', as both of us have done, or to accept the
bloat of around 50 packages and many megabytes of things like qt and kde
libraries.  I think the necessary background information to make that
decision was missing.

> You can always post the "PSA!!! DANGER ALERT! CODE RED" if you asked for
> information and did not get an answer that satisfied you, but the
> initial assumption of good faith would be appreciated.

> ....

> Regarding the daemontools situation:

> """
> for example with --depclean preserving packages in system, as well as world
> """

> Is not a valid suggestion, since --depclean already does precisely this,
> but openrc isn't a package in system, it is a package that satisfies a
> recursive dependency of system.

I think that's a rather obscure distinction.  Do users actually perceive
virtual packages this way?  I certainly don't.

> As far as portage knows, it is already doing exactly what you want it
> to do, as described in the Package Manager Specification.

My machine would have become unbootable long before I got around to
reading that spec.

> Perhaps you meant to say that --depclean should preserve all versions of
> an "any-of" dependency.

Yes, that's what I meant - at least those in @system.

> This would break a whole lot of use cases, as then one would no longer
> be able to change their system to suit themselves using the intended
> power of virtuals.

What is wrong with # emerge --unmerge?  I fail to see why that isn't
entirely satisfactory.

> For example, it would become impossible for a user to install s6-rc into
> their world file, with the intention of using s6-rc as their service
> manager, and then --depclean and remove openrc which they no longer
> intend to use!

# emerge --unmerge openrc.

> (It would also be impossible to install vim or emacs, then uninstall
> nano. For that matter, it would be impossible for an emacs user to
> install vim, try it out for a day, decide they don't like it, and
> uninstall vim. Vim would be there to stay: forever.)

What about the users, who can't be all that rare, who wish all of nano,
vim, and emacs to be installed?  They're application programs, not system
services.

> Normally, installing s6-rc is an intentional action to use s6-rc. But
> apparently, "normally" installing daemontools isn't an intentional
> action to use daemontools.

Yes.

> Thus, reporting this as a bug against portage is illogical, but
> reporting it as a bug against virtual/service-manager is logical. I can
> understand why a bug submitted "about --depclean" would be closed as
> not-a-bug, since it is... not, in fact, a bug, there is a totally
> different bug.

> Perhaps the person who closed that bug should have thought deeper about
> the implications of such a thing, and reassigned that bug to the correct
> package with a fixed explanation. And perhaps you should have
> communicated better why it's a problem for you to install daemontools
> *without intending to* and having that affect openrc. For example, by
> highlighting that daemontools isn't being used as a service manager and
> you do not believe installing "ordinary applications such as qmail"
> should be allowed to override your choice of init system.

> -- 
> Eli Schwartz

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: [gentoo-user] --depclean and openrc [Was: Wayland! Beware of!]

[Eli Schwartz]

[-- Attachment #1.1: Type: text/plain, Size: 2893 bytes --]

On 9/24/24 2:53 PM, Alan Mackenzie wrote:
>> Regarding the daemontools situation:
> 
>> """
>> for example with --depclean preserving packages in system, as well as world
>> """
> 
>> Is not a valid suggestion, since --depclean already does precisely this,
>> but openrc isn't a package in system, it is a package that satisfies a
>> recursive dependency of system.
> 
> I think that's a rather obscure distinction.  Do users actually perceive
> virtual packages this way?  I certainly don't.
> 
>> As far as portage knows, it is already doing exactly what you want it
>> to do, as described in the Package Manager Specification.
> 
> My machine would have become unbootable long before I got around to
> reading that spec.


Indeed, you are correct, but I am not sure why you'd need to read the
spec anyway.

That is why I am correct too -- since I am pointing out that things like
requesting specific portage / PMS behavior when interacting with virtual
packages is not how one should perceive the end-user problem.

(A virtual package is "just" a package with no installed files. How
virtual packages are used is a matter of Gentoo policy, not a matter of
how portage works. And PMS only mentions virtual packages once, and that
one time is to state that the old way was removed from the spec and that
new style virtuals are "just packages, and have no special treatment".)

Since it is "just a package", the solution should lie in fixing
::gentoo, not in fixing the "emerge" command. That's what the re-opened
bug is about. :)


>> This would break a whole lot of use cases, as then one would no longer
>> be able to change their system to suit themselves using the intended
>> power of virtuals.
> 
> What is wrong with # emerge --unmerge?  I fail to see why that isn't
> entirely satisfactory.


Recommending an option that can break your system is a workaround, not a
solution. Surely we want to end up in a good state of affairs, eventually?

The emerge manpage warns you against using --unmerge for good reason.


>> (It would also be impossible to install vim or emacs, then uninstall
>> nano. For that matter, it would be impossible for an emacs user to
>> install vim, try it out for a day, decide they don't like it, and
>> uninstall vim. Vim would be there to stay: forever.)
> 
> What about the users, who can't be all that rare, who wish all of nano,
> vim, and emacs to be installed?  They're application programs, not system
> services.


If you want all 3, then virtual/editor isn't an appropriate way to
install a large collection of apps. Add them to your world file.

virtual/editor doesn't restrict how many editors you have installed, it
simply requires you have at least one.

And it shouldn't require that any editors you install, cannot be
uninstalled with --depclean



-- 
Eli Schwartz


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 236 bytes --]

Re: [gentoo-user] Wayland! Beware of!

[Walter Dnes]

On Mon, Sep 23, 2024 at 05:11:14PM -0400, Eli Schwartz wrote

> Do you have that little faith in the Gentoo Developers, that you
> think we'd make a USE flag change that made everyone's systems
> suddenly break?
> 
> :(

  I was around way back when "ipv6" became the default.  I was using
Firefox back then.  Type in a URL; Firefox spins its wheels for 60
seconds in IPV6; it finally gives up and drops down to IPV4.  This
happened with every URL.

  After that I ran with USE="-* yada yada yada" for quite some time.
Currently, I'm less extreme, merely disabling a bunch of USE flags...

USE="X apng ffmpeg introspection jpeg opengl openmp png truetype x264 x265 xorg threads vala -acl -caps -clang -context -elogind -filecaps -graphite -gstreamer -haptic -iptables -ipv6 -libav -llvm -manpager -pam -sendmail -spirv -tofu -su -udisks -upower -wayland"

  The "szip" and "xinerama" USE flags seem to have disappeared.

  And who can forget the move from /dev/hda hdb hdc etc., to /dev/sda
sdb sdc etc.?  Machine literally unbootable on the newly compiled
kernel.  Fortunately, I always have "Production" and "Experimental"
kernels.  The newly compiled kernel is always "Experimental".  If things
go badly, I drop back to the "Production" kernel and try to figure out
what went wrong.  Only after a long while do I execute my "promote"
script that copies "Experimental" over top of "Production".

-- 
There are 2 types of people
1) Those who can extrapolate from incomplete data

Re: What is what (Re: [gentoo-user] Wayland! Beware of!)

[Wols Lists]

On 24/09/2024 19:32, karl@aspodata.se wrote:
> So should computer words be defined by non-professionals or thoose
> who knows ?
> 
Well, before computers, I thought servers worked in restaurants ...

(And what the hell are thoose :-)

> One effect of letting non-professionals define words is the case when
> the poeple handling the collection of television licences had the
> opinion the a computer is a television set and hence people with a
> computer should pay for the right to view television.

Well, given the number of times I've had to explain to professionals how 
they should be doing their *own* job, I really don't think they are the 
right people to be let loose on a dictionary ... your typical 
professional is paid to do, not to think, and boy do they make a point 
of NOT thinking ... (unless they're absolutely forced to, of course.)

(Oh - and if you're talking about the UK licence fee, I've had my 
arguments with them about their ability to understand plain English - 
like the EXPLICIT wording on the licence "if you are living away from 
home eg as a student, you are covered by your home licence if your tv is 
not plugged in to the mains". So they demanded my student daughter have 
her own licence for her battery-powered tv!)

At the end of the day, jargon is jargon. What matters is that we have a 
STANDARD. And whether you like it or not, the STANDARD says that X is 
using the words the wrong way round. Never mind that X pre-dates the 
standard.

It's when people who should know better redefine words that things get 
hairy - like the computing professor who used "real time" when he meant 
"online" or "interactive". And got rather upset when I pointed out that 
"interactive" and "real time" were different and confusing the two could 
cause real harm.

Or those plain idiots who insist on using the word "memory" and refuse 
to learn the difference between RAM and disk.

At the end of the day, the meaning of any individual work is irrelevant. 
What matters is that we have a shared understanding, a STANDARD.

The only thing that bothers me is those idiots who expect me to be a 
mind reader, and who expect me to realise when they use the word A, they 
actually want me to understand the word B. I don't care whether the word 
"server" means a restaurant waiter, some computer in a computer room 
somewhere, Xorg, or what. Just so long as I have a shared understanding 
with the person I'm talking to, and they don't expect me to mind-read 
because they can't be bothered to use the right word in the right context.

Cheers,
Wol

Re: [gentoo-user] Wayland! Beware of!

[Matt Jolly]

On 24/9/24 19:46, Mitchell Dorrell wrote:
> Do you specifically use the closed-source drivers, though?

Yes. In both the 'kernel-open' and regular flavours.

Re: [gentoo-user] --depclean and openrc [Was: Wayland! Beware of!]

[Matt Jolly]

Hi Alan,

On 25/9/24 04:53, Alan Mackenzie wrote:
> Perhaps.  As already said, I would have been much less jumpy if the
> explanations which have come in this thread had been in a news item.

As has been mentioned here this was not news-worthy. There is no
decision to make or mandatory migration. Users on the desktop
profile have simply transparently been rolled forward with a USE flag
change as happens with some regularity.

> With this change involving wayland, users HAVE to make a decision, namely
> whether to set USE='-wayland', as both of us have done, or to accept the
> bloat of around 50 packages and many megabytes of things like qt and kde
> libraries.  I think the necessary background information to make that
> decision was missing.

Most users of a desktop profile already made their decision: to trust
the distribution developers to make sane decisions on their behalf, and
to deviate from the default when they have a need to.

At the end of the day, unless your workstation is a literal 1990s potato
you can spare the disk space and CPU time for Wayland if you're on a
desktop profile. Users that really care about these things are
encouraged to carefully inspect each of the USE flags changed on a world
update (and ideally are familiar with Gentoo VCS) so that they can
inform themselves when a change comes around.

Cheers,

Matt

Re: [gentoo-user] Wayland! Beware of!

[Eli Schwartz]

[-- Attachment #1.1: Type: text/plain, Size: 5056 bytes --]

On 9/24/24 6:00 PM, Walter Dnes wrote:
> On Mon, Sep 23, 2024 at 05:11:14PM -0400, Eli Schwartz wrote
> 
>> Do you have that little faith in the Gentoo Developers, that you
>> think we'd make a USE flag change that made everyone's systems
>> suddenly break?
>>
>> :(
> 
>   I was around way back when "ipv6" became the default.  I was using
> Firefox back then.  Type in a URL; Firefox spins its wheels for 60
> seconds in IPV6; it finally gives up and drops down to IPV4.  This
> happened with every URL.


Please do not disable the USE=ipv6, as that is *utterly* insane. It also
does approximately nothing. In packages which support this USE flag,
which is rare, it causes the code to use old, untested APIs which only
support ipv4, rather than new, tested APIs that support ipv4 and ipv6
equally well while having the benefit of being stable, reliable and
efficient.

These old deprecated codepaths are prone to crashing and segfaulting
because the codebase for it is not enabled by anyone and the original
implementations are only kept around for the benefit of e.g. ancient
static binaries that cannot be rebuilt.

USE=ipv6 does not mean "ewww, evil bloated ipv6 socket functions".

It has NO influence on whether you use ipv4 or ipv6 traffic, as the vast
majority of the software you use doesn't even support the option, they
simply use maintained functions that just ask the kernel to give you
some internet traffic.

If you actually want to disable ipv6, instead of insanely rebuilding
binaries to use untested broken segfaulting code, use the sysctl knob to
tell the kernel "when asked to give some application a bit of internet
traffic, don't use ipv6".

net.ipv6.conf.all.disable_ipv6

This will:

- actually work

- work with applications that unconditionally use non-deprecated generic
  socket APIs

- not crash when running untested code, because the code is actually
  tested


Believe you me -- I am **very** aware of the painfulness inherent in
applications trying ipv6, failing, not knowing they cannot use ipv6, and
eventually timing out.

I historically solved it with the sysctl because my ISP had
broken/nonexistent ipv6, I continue to solve it with the sysctl when my
network cannot handle ipv6, and I will solve it with the sysctl in the
future when my network cannot handle ipv6.

I do not "solve" ipv6 by building 0.05% of my applications with
crash-prone APIs just because those APIs are also so old they predate ipv6.

The new APIs support ipv4 quite well; use them.

I'm sorry to hear you "broke" your own system through your own stubborn
ignorance. At no point did Gentoo developers ever break your ipv4, you
are imagining it.


>   After that I ran with USE="-* yada yada yada" for quite some time.
> Currently, I'm less extreme, merely disabling a bunch of USE flags...
> 
> USE="X apng ffmpeg introspection jpeg opengl openmp png truetype x264 x265 xorg threads vala -acl -caps -clang -context -elogind -filecaps -graphite -gstreamer -haptic -iptables -ipv6 -libav -llvm -manpager -pam -sendmail -spirv -tofu -su -udisks -upower -wayland"
> 
>   The "szip" and "xinerama" USE flags seem to have disappeared.


That's quite the bloated collection of enabled USE flags you have there
-- lots of stuff that are much more bloated than ipv6, in fact. :)

And really, you despise app-text/manpager with such ferocity that you
have to set a global USE for it lest a second program come to add that USE?

You hate /usr/bin/su so much that it's simply intolerable that
util-linux might build it?

But support for animated PNG files is too precious and dear to you, that
feature you absolutely have to have. Oh no, the bloat! We will be buried
under it!

...

But using a tested ipv4 codepath instead of an untested ipv4 codepath is
too much bloat for you, so you'd rather the crashes and the segfaults.
Brilliant.


>   And who can forget the move from /dev/hda hdb hdc etc., to /dev/sda
> sdb sdc etc.?  Machine literally unbootable on the newly compiled
> kernel.  Fortunately, I always have "Production" and "Experimental"
> kernels.  The newly compiled kernel is always "Experimental".  If things
> go badly, I drop back to the "Production" kernel and try to figure out
> what went wrong.  Only after a long while do I execute my "promote"
> script that copies "Experimental" over top of "Production".


That's quite the long-term grudge you have there. "Who can forget" it
indeed. ;) How about: pretty much everyone. What a tempest in a teapot.

(Even if I took this rant seriously, that wasn't anything the Gentoo
developers did. What's your proposed remediation, stay on the earlier
editions of kernel 2.6 for another 15 years because "that newfangled 2.6
kernel man, that's just totally breaking my system"?)

Your kernel testing and rotation management is boringly plebeian, as
it's what approximately every other Gentoo system does by default
without any configuration needed.


-- 
Eli Schwartz


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 236 bytes --]

Re: [gentoo-user] Wayland! Beware of!

[Walter Dnes]

On Tue, Sep 24, 2024 at 09:42:23PM -0400, Eli Schwartz wrote

> If you actually want to disable ipv6, instead of insanely rebuilding
> binaries to use untested broken segfaulting code, use the sysctl
> knob to tell the kernel "when asked to give some application a bit
> of internet traffic, don't use ipv6".
> 
> net.ipv6.conf.all.disable_ipv6

  My system is actually very stable.  In the shitstorm that erupted on
this list at "ipv6" enabling I did not see any mention of sysctl.  In my
/etc/default/grub file I have...

GRUB_CMDLINE_LINUX_DEFAULT="noexec=on net.ifnames=0 ipv6.disable=1"

With this setting is it guaranteed that a program compiled with "ipv6"
flag will not try IPV6 first and timeout before dropping down to IPV4?

  How OS-specific is this?  I "asked Mr. Google" and the NordVPN web
page recommended for Redhat based distros...

net.ipv6.conf.all.disable_ipv6=1
net.ipv6.conf.default.disable_ipv6=1
net.ipv6.conf.tun0.disable_ipv6=1

  For Debian-based distros...

net.ipv6.conf.all.disable_ipv6 = 1
net.ipv6.conf.default.disable_ipv6 = 1
net.ipv6.conf.lo.disable_ipv6 = 1
net.ipv6.conf.tun0.disable_ipv6 = 1

  Other answers for disabling IPV6 include stuff like...

net.ipv6.conf.all.disable_ipv6 = 1
net.ipv6.conf.default.disable_ipv6 = 1
net.ipv6.conf.lo.disable_ipv6 = 1
net.ipv6.conf.eth0.disable_ipv6 = 1

  BTW, I did *NOT* have IPV6 enabled when the USE flag changed...

[x8940][root][~] grep IPV6 /usr/src/linux/.config 
# CONFIG_IPV6 is not set



> That's quite the bloated collection of enabled USE flags you have
> there -- lots of stuff that are much more bloated than ipv6, in
> fact. :)

  Stuff that I don't use is left disabled.  I occasionally look at my
package.use file.  If a flag is enabled for multiple apps there, I run 

USE="flag" emerge -pv --changed-use --deep --pdate @world

If there isn't much new stuff pulled in I'll...

* enable the flag in make.conf
* delete the enabling entries in package.use
* disable, in package.use, the flag for new stuff that tha flag pulls in

This minimizes the size of my package.use file.  Note: this is optimal
for the collection of apps *THAT I USE*.  YMMV.

-- 
There are 2 types of people
1) Those who can extrapolate from incomplete data

Re: [gentoo-user] Wayland! Beware of!

[Arsen Arsenović]

[-- Attachment #1: Type: text/plain, Size: 3405 bytes --]

Walter Dnes <waltdnes@waltdnes.org> writes:

> On Tue, Sep 24, 2024 at 09:42:23PM -0400, Eli Schwartz wrote
>
>> If you actually want to disable ipv6, instead of insanely rebuilding
>> binaries to use untested broken segfaulting code, use the sysctl
>> knob to tell the kernel "when asked to give some application a bit
>> of internet traffic, don't use ipv6".
>> 
>> net.ipv6.conf.all.disable_ipv6
>
>   My system is actually very stable.  In the shitstorm that erupted on
> this list at "ipv6" enabling I did not see any mention of sysctl.  In my
> /etc/default/grub file I have...
>
> GRUB_CMDLINE_LINUX_DEFAULT="noexec=on net.ifnames=0 ipv6.disable=1"
>
> With this setting is it guaranteed that a program compiled with "ipv6"
> flag will not try IPV6 first and timeout before dropping down to IPV4?

That's not how IPv6 is supported.  Dual-stack support relies on 'happy
eyeballs', an algorithm by which both IPv4 and v6 are tried
optimistically, and the first one to succeed is accepted.  This adds no
latency.  I suspect your Firefox anecdote happened due to
misconfiguration (I think network.http.fast-fallback-to-IPv4 dictates
the use of this algorithm in Firefox).

As a point of reference, I do nothing to disable IPv6 support, and my
ISP does not provide IPv6 support, yet I have no added latency due to
IPv6 support being enabled.  I just get the benefits of better LANs and
internal networks.

There is no reason to disable IPv6 support, as Eli said (especially if
yo do not know _what_ you're trying to disable, and are just trying to
blanket-disable a vague concept of IPv6).

>   How OS-specific is this?

Not at all.

> I "asked Mr. Google" and the NordVPN web page recommended for Redhat
> based distros...
>
> net.ipv6.conf.all.disable_ipv6=1
> net.ipv6.conf.default.disable_ipv6=1
> net.ipv6.conf.tun0.disable_ipv6=1
>
>   For Debian-based distros...
>
> net.ipv6.conf.all.disable_ipv6 = 1
> net.ipv6.conf.default.disable_ipv6 = 1
> net.ipv6.conf.lo.disable_ipv6 = 1
> net.ipv6.conf.tun0.disable_ipv6 = 1
>
>   Other answers for disabling IPV6 include stuff like...
>
> net.ipv6.conf.all.disable_ipv6 = 1
> net.ipv6.conf.default.disable_ipv6 = 1
> net.ipv6.conf.lo.disable_ipv6 = 1
> net.ipv6.conf.eth0.disable_ipv6 = 1

Note that all of the above include interface names, this is why they
differ, and just copy-pasting them blindly will not work.

Note also that they're all identical, save for the interfaces mentioned.

>   BTW, I did *NOT* have IPV6 enabled when the USE flag changed...
>
> [x8940][root][~] grep IPV6 /usr/src/linux/.config 
> # CONFIG_IPV6 is not set
>
>
>
>> That's quite the bloated collection of enabled USE flags you have
>> there -- lots of stuff that are much more bloated than ipv6, in
>> fact. :)
>
>   Stuff that I don't use is left disabled.  I occasionally look at my
> package.use file.  If a flag is enabled for multiple apps there, I run 
>
> USE="flag" emerge -pv --changed-use --deep --pdate @world
>
> If there isn't much new stuff pulled in I'll...
>
> * enable the flag in make.conf
> * delete the enabling entries in package.use
> * disable, in package.use, the flag for new stuff that tha flag pulls in
>
> This minimizes the size of my package.use file.  Note: this is optimal
> for the collection of apps *THAT I USE*.  YMMV.
-- 
Arsen Arsenović

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 381 bytes --]

Re: [gentoo-user] Wayland! Beware of!

[Eli Schwartz]

[-- Attachment #1.1: Type: text/plain, Size: 2425 bytes --]

On 9/25/24 6:00 AM, Walter Dnes wrote:
>   My system is actually very stable.  In the shitstorm that erupted on
> this list at "ipv6" enabling I did not see any mention of sysctl.  In my
> /etc/default/grub file I have...
> 
> GRUB_CMDLINE_LINUX_DEFAULT="noexec=on net.ifnames=0 ipv6.disable=1"
> 
> With this setting is it guaranteed that a program compiled with "ipv6"
> flag will not try IPV6 first and timeout before dropping down to IPV4?


(Note that the sysctl dynamically disables ipv6 support so that you can
manually toggle it after boot, e.g. for testing. The kernel command line
option hard-disables it at boot time. Your choice which to use, I guess.)


If the kernel has disabled ipv6 there is no timeout because no attempt
is made.

If the kernel has enabled ipv6 then an attempt will be made and it may:

- succeed, if your network has functioning ipv6 connectivity

- fail instantly, if your network is correctly configured (you may not
  be in control of the network you use)

- fail after a lengthy timeout after your network "valiantly" attempts
  to send your connection attempt into a black hole of doom

As Arsen mentioned, RFC 8305 defines the "Happy Eyeballs" mechanism for
trying both ipv4 and ipv6 at the same time, incurring the cost of
slightly more traffic for the benefit of avoiding timeouts (since ipv4
will still succeed just as fast regardless of whether a parallel ipv6 is
timing out, and as soon as ipv4 succeeds, the ipv6 timeout is ignored
and made redundant).

Not all software uses Happy Eyeballs. In particular, emerge --sync does
not, because the python library that portage uses to check for updated
PGP keys used when validating manifests, does not. This pained me
tremendously since "emerge --sync" would literally hang forever, until I
disabled ipv6 via the kernel. Note that since Aug 31, 2021, Gentoo's
package for python has not supported USE=ipv6, but the sysctl works
quite well.


>   How OS-specific is this?  I "asked Mr. Google" and the NordVPN web
> page recommended for Redhat based distros...


It is specific to the linux kernel, that is all. You may replace "all"
with the name of a machine-specific interface (as listed by "ip addr")
to express settings that are specific to a given interface. Most people
do not need that flexibility and simply want all interfaces to look the
same.


-- 
Eli Schwartz


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 236 bytes --]

Re: [gentoo-user] Wayland! Beware of!

[jay]

On 9/25/24 7:26 AM, Eli Schwartz <eschwartz@gentoo.org> wrote:
> On 9/25/24 6:00 AM, Walter Dnes wrote:
> >    My system is actually very stable.  In the shitstorm that erupted on
> > this list at "ipv6" enabling I did not see any mention of sysctl.  In my
> > /etc/default/grub file I have...
> >
> > GRUB_CMDLINE_LINUX_DEFAULT="noexec=on net.ifnames=0 ipv6.disable=1"
> >
> > With this setting is it guaranteed that a program compiled with "ipv6"
> > flag will not try IPV6 first and timeout before dropping down to IPV4?
> 
> 
> (Note that the sysctl dynamically disables ipv6 support so that you can
> manually toggle it after boot, e.g. for testing. The kernel command line
> option hard-disables it at boot time. Your choice which to use, I guess.)
> 
> 
> If the kernel has disabled ipv6 there is no timeout because no attempt
> is made.
> 
> If the kernel has enabled ipv6 then an attempt will be made and it may:
> 
> - succeed, if your network has functioning ipv6 connectivity
> 
> - fail instantly, if your network is correctly configured (you may not
>    be in control of the network you use)
> 
> - fail after a lengthy timeout after your network "valiantly" attempts
>    to send your connection attempt into a black hole of doom
> 

This was actually a pretty common failure mode around 10-15 years ago. An
early Apple Airport Express had a bug where it would issue global-scope v6
addresses and send RAs even if it didn't have global connectivity.

Those issues (and similar ones on less ubiquitus routers), fed a lot of the
paranoia around desires to disable IPv6. It still can happen today, but IME
it's more often in the form of an ISP with inferior IPv6 connectivity.

--
Jay Faulkner

> As Arsen mentioned, RFC 8305 defines the "Happy Eyeballs" mechanism for
> trying both ipv4 and ipv6 at the same time, incurring the cost of
> slightly more traffic for the benefit of avoiding timeouts (since ipv4
> will still succeed just as fast regardless of whether a parallel ipv6 is
> timing out, and as soon as ipv4 succeeds, the ipv6 timeout is ignored
> and made redundant).
> 
> Not all software uses Happy Eyeballs. In particular, emerge --sync does
> not, because the python library that portage uses to check for updated
> PGP keys used when validating manifests, does not. This pained me
> tremendously since "emerge --sync" would literally hang forever, until I
> disabled ipv6 via the kernel. Note that since Aug 31, 2021, Gentoo's
> package for python has not supported USE=ipv6, but the sysctl works
> quite well.
> 
> 
> >    How OS-specific is this?  I "asked Mr. Google" and the NordVPN web
> > page recommended for Redhat based distros...
> 
> 
> It is specific to the linux kernel, that is all. You may replace "all"
> with the name of a machine-specific interface (as listed by "ip addr")
> to express settings that are specific to a given interface. Most people
> do not need that flexibility and simply want all interfaces to look the
> same.
> 
> 
> 

Re: [gentoo-user] Wayland! Beware of!

[Walter Dnes]

On Wed, Sep 25, 2024 at 01:53:49PM +0200, Arsen Arsenović wrote

> I suspect your Firefox anecdote happened due to misconfiguration
> (I think network.http.fast-fallback-to-IPv4 dictates the use of this
> algorithm in Firefox).

  I do not recall ever touching it in about:config.  In my current
browser (Pale Moon) that setting is at its default value of "true".

> As a point of reference, I do nothing to disable IPv6 support, and my
> ISP does not provide IPv6 support, yet I have no added latency due to
> IPv6 support being enabled.  I just get the benefits of better LANs and
> internal networks.
> 
> There is no reason to disable IPv6 support, as Eli said (especially if
> yo do not know _what_ you're trying to disable, and are just trying to
> blanket-disable a vague concept of IPv6).

  This is *NOT* about a "vague concept".  This is about solving a bug
that makes browsing unbearable.  I'm not the only one.  See archive
https://public-inbox.gentoo.org/gentoo-user/14d2d8af-e7b9-d5e6-06c1-a7f3ad01ac23@gmail.com/

> When syncing portage today I saw what the delay is: apparently it
> tries ipv6 twice, fails, then resorts to ipv4 which works fine.
> 
> Most of my systems now have ipv6 support removed, and viola! no
> more delays.

  In his case, the delay was only 10 seconds, but a delay nonetheless.
This raises another point, it was not just Firefox that ran into
problems, but rather anything that talked to the internet.

  Back in January, my ISP migrated me from cable to fibre.  I went from
legacy 10 mbits down 1 up, 200 gigabytes/month quota, to "30 mbits
symmetric unlimited" for the same price.  The fibre service does have
IPV6 enabled, and I'll get around to going IPV6 one of these days,
especially if there's a "flag day" shutdown of IPV4.

-- 
There are 2 types of people
1) Those who can extrapolate from incomplete data

Re: [gentoo-user] Wayland! Beware of!

[Michael Orlitzky]

On 2024-09-24 21:42:23, Eli Schwartz wrote:
> 
> Please do not disable the USE=ipv6, as that is *utterly* insane. It also
> does approximately nothing. In packages which support this USE flag,
> which is rare, it causes the code to use old, untested APIs which only
> support ipv4, rather than new, tested APIs that support ipv4 and ipv6
> equally well while having the benefit of being stable, reliable and
> efficient.

I think this greatly depends on the package. djbdns is fresh on my
mind, and djbdns[ipv6] will pull in a massive third-party patch to add
support for serving ipv6 records. The changes are so pervasive that
(a) they required manually re-rolling several ipv4 security patches,
and (b) may reintroduce some of the same security issues over ipv6, if
nobody is filing CVEs against the patch. It's not clear-cut, but you
can certainly argue that you're better off without USE=ipv6 if you're
not serving ipv6 records.

Pkgcheck has been warning about "bad" instances of USE=ipv6 for some
time now. The longer the warning stays in place, the more packages we
can expect to import some special useful meaning to it.

Re: [gentoo-user] Wayland! Beware of!

[Eli Schwartz]

[-- Attachment #1.1: Type: text/plain, Size: 3511 bytes --]

On 9/25/24 6:21 PM, Walter Dnes wrote:
>> There is no reason to disable IPv6 support, as Eli said (especially if
>> yo do not know _what_ you're trying to disable, and are just trying to
>> blanket-disable a vague concept of IPv6).
> 
>   This is *NOT* about a "vague concept".  This is about solving a bug
> that makes browsing unbearable.


I think the two of you are talking past each other. What did Arsen mean
by "the vague concept of IPv6"? I suspect he meant:

You are trying to solve a concrete user issue with your browsing.

Your idea of how to solve the user issue is to blame IPv6, then get all
meta about how to solve it and decide that the vague concept of IPv6
must be eradicated and purged from the public consciousness -- rather
than disabling the specific issue that is causing problems.


> I'm not the only one.  See archive
> https://public-inbox.gentoo.org/gentoo-user/14d2d8af-e7b9-d5e6-06c1-a7f3ad01ac23@gmail.com/
> 
>> When syncing portage today I saw what the delay is: apparently it
>> tries ipv6 twice, fails, then resorts to ipv4 which works fine.
>>
>> Most of my systems now have ipv6 support removed, and viola! no
>> more delays.
> 
>   In his case, the delay was only 10 seconds, but a delay nonetheless.
> This raises another point, it was not just Firefox that ran into
> problems, but rather anything that talked to the internet.


Hmm, that's basically what I said up-thread too. :) Portage, like many
other packages, talks to the internet and can have timeouts when IPv6 is
broken.

And there is no USE=ipv6 to disable for portage, nor for
dev-lang/python, nor for dev-python/requests. So how do you fix the problem?

Via the kernel command line or the sysctl. Easy.

In the thread you link to, people spent days blaming systemd for
"blocking ipv6 removal in our kernel .config" and had to switch init
systems just so they could reconfigure and rebuild their kernel.

Eventually someone suggested setting ipv6.disable_ipv6=1 on the kernel
command line. But the person with the original issue had already, by
that time,

"""
managed to switch back to openrc. That didn't go real smoothly, portage
couldn't figure out how to do it on it's own after switching profiles,
it was blindly removing and rebuilding some packages manually that
eventually made it work and not want to pull in systemd again
"""

and never actually bothered setting the kernel command line, nor
listening to the advice of the people in the thread who suggested that
the kernel .config option for systemd is not actually required to run
systemd, it's just a quick toggle for people who want to bulk-enable
settings that are best to use when running systemd.

And this is why rumors of how you need to set USE="-ipv6" to "make your
system stop timing out" spread. Because no one actually pays attention
to reality, and no one actually bothers to test the kernel command line
or sysctl options, so they spend days recompiling their system and
juggling USE flags and swapping back and forth between init systems in
the hope that it will stop the timeouts.

And all along it was literally a couple lines in a text file and one
`sysctl` command away, without even needing to reboot.

All it takes is people not running around like headless chickens.

All it takes is people not claiming that the Gentoo Developers have
"infamously made a USE flag change that made everyone's systems suddenly
break".



-- 
Eli Schwartz


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 236 bytes --]

Re: [gentoo-user] Wayland! Beware of!

[Walter Dnes]

On Wed, Sep 25, 2024 at 08:25:12PM -0400, Eli Schwartz wrote

> I think the two of you are talking past each other. What did Arsen mean
> by "the vague concept of IPv6"? I suspect he meant:
> 
> You are trying to solve a concrete user issue with your browsing.

  Correct.

> Your idea of how to solve the user issue is to blame IPv6, then get all
> meta about how to solve it and decide that the vague concept of IPv6
> must be eradicated and purged from the public consciousness

  You're overdoing it and you seem offended.  I was not "thinking deep
thoughts about IPV6" or going off the deep end with QANON conspiracies.
Back then I was unaware of the power of sysctl or using the kernel
command line.  All that I (and a lot of other people) knew was that...

USE="ipv6"  ==> delays and timeouts for people on IPV4-only systems

USE="-ipv6" ==> problems solved for people on IPV4-only systems

  This was simply a pragmatic decision to solve a problem.  Firefox
with USE="ipv6" probably would've worked OK on a machine with a working
IPV6 connection.

> -- rather than disabling the specific issue that is causing problems.

  Looking at the output of "sysctl -a | grep net.ip | less" *ON MY
SYSTEM*, I see a slew of "net.ipv4.*" entries, but no "net.ipv6.*"
entries, so there's no "sysctl knob" to tweak.

-- 
There are 2 types of people
1) Those who can extrapolate from incomplete data

Re: [gentoo-user] Wayland! Beware of!

[James Cloos]

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

WD>   This is *NOT* about a "vague concept".  This is about solving a bug
WD> that makes browsing unbearable.  I'm not the only one.  See archive
WD> https://public-inbox.gentoo.org/gentoo-user/14d2d8af-e7b9-d5e6-06c1-a7f3ad01ac23@gmail.com/

if you want your box always to prefer ipv4 over ipv6, edit /etc/gai.conf
and add this line:

precedence ::ffff:0:0/96  100

then the network stack will try ip6 addresses only for names which have
AAAA records but do not have A records in dns.

-JimC
-- 
James Cloos <cloos@jhcloos.com>
            OpenPGP: https://jhcloos.com/0x997A9F17ED7DAEA6.asc

Re: [gentoo-user] --depclean and openrc [Was: Wayland! Beware of!]

[Mitchell Dorrell]

[-- Attachment #1: Type: text/plain, Size: 1184 bytes --]

On Tue, Sep 24, 2024, 07:41 Arsen Arsenović <arsen@gentoo.org> wrote:

> I do wonder if we should keep s6, runit and daemontools in that virutal
> though, given that we can't boot them.  Perhaps they'd be fine behind a
> USE flag.  I'll propose that.
>

So, this is a case where you definitely always need one of the
dependencies, and sometimes you might want two, but the reason you might
want the second one would not be to fulfill the purpose represented by the
virtual.

It sounds to me like a set of local USE flags would be perfect, with a
REQUIRED_USE enforcing exactly-one-of to choose the dependency. The USE
flag controls the choice, and if you pull in an alternative service manager
for an unrelated reason, it doesn't change the USE flag, so it doesn't
change the dependency which satisfies the virtual. The USE-disabled service
managers are simply ignored.

Would that work? Or is that exactly what you're planning to propose?

I don't think using just one USE flag would be as safe, unless this is only
an issue for daemontools. Tons of stuff tries to pull in systemd, but
blockers generally prevent you from making a mess that way.

-MD

>

[-- Attachment #2: Type: text/html, Size: 1912 bytes --]

Re: [gentoo-user] --depclean and openrc [Was: Wayland! Beware of!]

[Alan Mackenzie]

Hello, Eli.

On Tue, Sep 24, 2024 at 15:36:43 -0400, Eli Schwartz wrote:
> On 9/24/24 2:53 PM, Alan Mackenzie wrote:
> >> Regarding the daemontools situation:

> >> """
> >> for example with --depclean preserving packages in system, as well as world
> >> """

> >> Is not a valid suggestion, since --depclean already does precisely this,
> >> but openrc isn't a package in system, it is a package that satisfies a
> >> recursive dependency of system.

> > I think that's a rather obscure distinction.  Do users actually perceive
> > virtual packages this way?  I certainly don't.

> >> As far as portage knows, it is already doing exactly what you want it
> >> to do, as described in the Package Manager Specification.

> > My machine would have become unbootable long before I got around to
> > reading that spec.


> Indeed, you are correct, but I am not sure why you'd need to read the
> spec anyway.

> That is why I am correct too -- since I am pointing out that things like
> requesting specific portage / PMS behavior when interacting with virtual
> packages is not how one should perceive the end-user problem.

> (A virtual package is "just" a package with no installed files. How
> virtual packages are used is a matter of Gentoo policy, not a matter of
> how portage works. And PMS only mentions virtual packages once, and that
> one time is to state that the old way was removed from the spec and that
> new style virtuals are "just packages, and have no special treatment".)

> Since it is "just a package", the solution should lie in fixing
> ::gentoo, not in fixing the "emerge" command. That's what the re-opened
> bug is about. :)

What is getting fixed are the data.  That leaves the same problem in the
emerge code to bite again the next time there are faulty data.

> >> This would break a whole lot of use cases, as then one would no longer
> >> be able to change their system to suit themselves using the intended
> >> power of virtuals.

> > What is wrong with # emerge --unmerge?  I fail to see why that isn't
> > entirely satisfactory.


> Recommending an option that can break your system is a workaround, not a
> solution. Surely we want to end up in a good state of affairs, eventually?

We've already established that --depclean can break one's system, not
just theoretically but in real world use.  --unmerge is surely safer -
you're unmerging specific packages which, presumably, you've already
checked for safety.

There doesn't appear to be anything better in emerge - I've looked but
not found an emerge action to unmerge specific packages only, apart from
--unmerge.  Why is there not a version of --unmerge which does safety
checks first?

The envisaged work flow seems to be doing things like --deselect,
followed by --depclean, praying that the latter isn't going to break the
system.  Given how much safer --unmerge is than --depclean, I don't
understand why the emerge man page puts a bold face warning right at the
start of --unmerge, but not on --depclean.

> The emerge manpage warns you against using --unmerge for good reason.

But doesn't state that reason or give a workable alternative.  Saying it
can remove important packages is unhelpful if it doesn't give an
alternative which can't.

My current workflow for clearing out orphaned packages is to do emerge
-p --depclean, then use emerge --unmerge on those packages listed which
aren't critical system packages or needed application programs.

> >> (It would also be impossible to install vim or emacs, then uninstall
> >> nano. For that matter, it would be impossible for an emacs user to
> >> install vim, try it out for a day, decide they don't like it, and
> >> uninstall vim. Vim would be there to stay: forever.)

> > What about the users, who can't be all that rare, who wish all of
> > nano, vim, and emacs to be installed?  They're application programs,
> > not system services.


> If you want all 3, then virtual/editor isn't an appropriate way to
> install a large collection of apps. Add them to your world file.

virtual/editor is an obscure internal mechanism of portage.  If I emerge
vim, and emerge Emacs, I expect portage to respect my intentions, as
well as not assuming I want rid of nano or anything else in @system.

> virtual/editor doesn't restrict how many editors you have installed, it
> simply requires you have at least one.

> And it shouldn't require that any editors you install, cannot be
> uninstalled with --depclean

--depclean is too clumsy.  It assumes I want to unmerge nano, for reasons
which are surely not intended UI, but just because that's the way it was
implemented.  I think a --ask flag only asks whether to delete all listed
packages or none, not each package individually.  What I would prefer is
an interface by which _I_ specify which packages are to be removed.

> -- 
> Eli Schwartz

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: [gentoo-user] --depclean and openrc [Was: Wayland! Beware of!]

[Walter Dnes]

On Fri, Oct 25, 2024 at 07:22:01PM +0000, Alan Mackenzie wrote
> 
> There doesn't appear to be anything better in emerge - I've looked but
> not found an emerge action to unmerge specific packages only, apart from
> --unmerge.  Why is there not a version of --unmerge which does safety
> checks first?

  I've cobbled together a script of my own to handle this.  It's
/root/bin/autodepclean : NOTE: it does *NOT* clean out anything.
Rather, it generates a script "cleanscript" in the current directory.
The idea is that you inspect it first before running ./cleanscript

##########################################

#!/bin/bash
# autodepclean script v 0.04 released under GPL v3 by Walter Dnes
# 2023/02/18 Generates a file "cleanscript" in the current directory to
# remove unused ebuilds, including buildtime-only dependancies.
#
# Warning; this script is beta.  I recommend that you check the output
# in cleanscript before running it.
#
# With the arrival of "virtual/editor", the script now suggests removing
# app-editors/nano, which may not be what you want.  If you want to keep
# nano, put it into world.
#
# version 0.03 disables the removal of gentoo-sources.  Your current kernel
# is not always the most recent one in /usr/src.
#
# version 0.04 adds "--verbose" to the "emerge --depclean".  This makes it
# easier to track down circular dependancies.
#
# version 0.05 wipes cleanscript if no files to process.  This guards
# against the edge case of running a flat "emerge --depclean" if there
# are no ebuilds to remove.

echo "#!/bin/bash" > cleanscript
echo "#" >> cleanscript
echo "emerge --depclean \\" >> cleanscript
emerge --pretend --depclean |\
  grep -A1 "^ .*/" |\
  grep -v "^ \*" |\
  grep -v "^--" |\
  sed ":/: {
N
s:\n::
s/    selected: /-/
s/^ / =/
s/$/ \\\/
}" | grep -v "=app-editors/nano" |\
grep -v "=sys-kernel/gentoo-sources" |\
grep -v "=sys-devel/gcc-" >> cleanscript
echo ' ; echo ""' >> cleanscript
echo "revdep-rebuild" >> cleanscript
chmod 744 cleanscript
if grep "=" cleanscript >> /dev/null 2>&1 ;
then
  echo "OK to proceed."
else
  echo "" > cleanscript
  echo "Nothing to process"
fi

##########################################

  I last updated my system 32 days ago.  When I ran "autodepclean" after
updating world today, it generated the following "cleanscript"

##########################################

#!/bin/bash
#
emerge --depclean \
 =net-dns/bind-tools-9.18.0  \
 =dev-python/pip-24.2-r1  \
 =dev-build/autoconf-2.71-r7  \
 =dev-python/typing-extensions-4.12.2  \
 =dev-python/truststore-0.9.2  \
 =dev-python/rich-13.7.1  \
 =dev-python/resolvelib-1.0.1  \
 =dev-python/pyproject-hooks-1.1.0  \
 =dev-python/distro-1.9.0  \
 =dev-python/distlib-0.3.8  \
 =dev-python/cachecontrol-0.14.0  \
 =dev-python/requests-2.32.3  \
 =dev-python/poetry-core-1.9.0  \
 =dev-python/msgpack-1.0.8  \
 =dev-python/markdown-it-py-3.0.0  \
 =dev-python/colorama-0.4.6  \
 =dev-python/urllib3-2.2.2  \
 =dev-python/mdurl-0.1.2  \
 =dev-python/linkify-it-py-2.0.3  \
 =dev-python/lark-1.2.2  \
 =dev-python/idna-3.8  \
 =dev-python/fastjsonschema-2.20.0  \
 =dev-python/charset-normalizer-3.3.2  \
 =dev-python/certifi-3024.7.22  \
 =dev-python/uc-micro-py-1.0.3  \
 =dev-python/PySocks-1.7.1-r2  \
 ; echo ""
revdep-rebuild

##########################################

  autodepclean takes out a lot of "virtual-perl" packages after a perl
update, but doesn't cause problems.

-- 
There are 2 types of people in this world
1) Those who can extrapolate from incomplete data

Re: [gentoo-user] --depclean and openrc [Was: Wayland! Beware of!]

[Eli Schwartz]

[-- Attachment #1.1: Type: text/plain, Size: 5418 bytes --]

On 10/25/24 3:22 PM, Alan Mackenzie wrote:
>> Since it is "just a package", the solution should lie in fixing
>> ::gentoo, not in fixing the "emerge" command. That's what the re-opened
>> bug is about. :)
> 
> What is getting fixed are the data.  That leaves the same problem in the
> emerge code to bite again the next time there are faulty data.


I would argue the precise opposite, that the job of emerge is to
faithfully do what you tell it to do and the job of ::gentoo is to not
tell emerge to do stupid things.

We should fix bugs, not break tools by assuming bugs won't be fixed.

Especially when no clear proposal about how emerge should be changed
exists (ideally in the form of a detailed feature request on the Portage
bugtracker).


>> Recommending an option that can break your system is a workaround, not a
>> solution. Surely we want to end up in a good state of affairs, eventually?
> 
> We've already established that --depclean can break one's system, not
> just theoretically but in real world use.  --unmerge is surely safer -
> you're unmerging specific packages which, presumably, you've already
> checked for safety.


"we" have established no such thing. You claim that --depclean can break
one's system, I disputed this notion and claim that
virtual/service-manager can break one's system.

You may argue all you want -- I cannot provide any guarantees about
whether other people will agree with you that the problem is portage,
but I'm always open to hearing persuasive arguments.

On that note I am happy that there was reasonable discussion on the bug
report at https://bugs.gentoo.org/803878 but also somewhat disappointed
that despite what seems like a lot of support for making the proposed
fix, no one has actually stepped up and made that fix yet...


> There doesn't appear to be anything better in emerge - I've looked but
> not found an emerge action to unmerge specific packages only, apart from
> --unmerge.  Why is there not a version of --unmerge which does safety
> checks first?
> 
> The envisaged work flow seems to be doing things like --deselect,
> followed by --depclean, praying that the latter isn't going to break the
> system.  Given how much safer --unmerge is than --depclean, I don't
> understand why the emerge man page puts a bold face warning right at the
> start of --unmerge, but not on --depclean.


I find this wording confusing and difficult to understand on your part.

There is no option to unmerge specific packages only, using "--unmerge".
I just tried it:

```
# emerge --unmerge

emerge unmerge can only be used with specific package names
```

Oops? Your claims are totally invalid.

I am nitpicking about this for an extremely good reason. Since --unmerge
requires you to *specify the package name* (and since you have used it a
lot, you surely know this fact) I don't think it should come as a shock that

```
# emerge --depclean CAT/MYPKG
```

also works. And, lo and behold -- it is a version of --unmerge that
unmerges specific packages only, which does safety checks first.

This is also how I use --depclean by the way. I generally never depclean
all packages, I take a look at what "emerge --depclean --pretend"
suggests can be depcleaned and then decide whether I want to selectively
depclean some of them by name.

I will say that I wish --depclean accepted glob patterns which would
then match only on packages which are eligible for default-depcleaning.
I have a small awk script that processes the output of "emerge -cpq" to
select packages that aren't required by @world which match specific
patterns such as language-specific categories for libraries, so e.g. I
can depclean "all dev-perl stuff unless another package needs it"...

>> The emerge manpage warns you against using --unmerge for good reason.
> 
> But doesn't state that reason or give a workable alternative.  Saying it
> can remove important packages is unhelpful if it doesn't give an
> alternative which can't.
> 
> My current workflow for clearing out orphaned packages is to do emerge
> -p --depclean, then use emerge --unmerge on those packages listed which
> aren't critical system packages or needed application programs.


... again, it literally says to use --depclean, but I'm increasingly
getting the feeling that you are not *aware* that --depclean accepts
package names. I find this odd, since the manpage entry for --depclean
says it pretty clearly:

"""
Depclean serves as a dependency aware version of --unmerge. When given
one or more atoms, it will unmerge matched packages that have no reverse
dependencies.
"""


> --depclean is too clumsy.  It assumes I want to unmerge nano, for reasons
> which are surely not intended UI, but just because that's the way it was
> implemented.  I think a --ask flag only asks whether to delete all listed
> packages or none, not each package individually.  What I would prefer is
> an interface by which _I_ specify which packages are to be removed.


Implementing a per-package ask seems like it would be challenging, as it
would have to go back and recalculate which packages can still be asked
about if you respond "no" to some package that other packages depend on.

It does sound like an interesting idea though -- maybe worth submitting
a feature request?



-- 
Eli Schwartz

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 236 bytes --]

Re: [gentoo-user] --depclean and openrc [Was: Wayland! Beware of!]

[Alan Mackenzie]

Hello, Eli.

On Sat, Oct 26, 2024 at 21:53:15 -0400, Eli Schwartz wrote:
> On 10/25/24 3:22 PM, Alan Mackenzie wrote:
> >> Since it is "just a package", the solution should lie in fixing
> >> ::gentoo, not in fixing the "emerge" command. That's what the re-opened
> >> bug is about. :)

> > What is getting fixed are the data.  That leaves the same problem in the
> > emerge code to bite again the next time there are faulty data.


> I would argue the precise opposite, that the job of emerge is to
> faithfully do what you tell it to do and the job of ::gentoo is to not
> tell emerge to do stupid things.

> We should fix bugs, not break tools by assuming bugs won't be fixed.

Software should guard against stupid inputs.

> Especially when no clear proposal about how emerge should be changed
> exists (ideally in the form of a detailed feature request on the Portage
> bugtracker).

I've already made specific suggestions on this list, and they have not,
in general, been well enough received to make the extra effort of
submitting bugs worthwhile.

For example, I suggested that emerge shouldn't remove @system packages
without a specific request or confirmation from the user.

> >> Recommending an option that can break your system is a workaround, not a
> >> solution. Surely we want to end up in a good state of affairs, eventually?

> > We've already established that --depclean can break one's system, not
> > just theoretically but in real world use.  --unmerge is surely safer -
> > you're unmerging specific packages which, presumably, you've already
> > checked for safety.


> "we" have established no such thing. You claim that --depclean can break
> one's system, I disputed this notion and claim that
> virtual/service-manager can break one's system.

As a user, as opposed to a gentoo maintainer, that distinction is
meaningless.  If gentoo breaks my system, I will be upset and angry
regardless of such fine distinctions.

It's looking like virtual/service-manager is finally getting fixed
(thanks for the prodding!).  But the same thing, system critical
components being removed by --depclean, might well happen again, since
emerge isn't being amended to prevent it.

> You may argue all you want -- I cannot provide any guarantees about
> whether other people will agree with you that the problem is portage,
> but I'm always open to hearing persuasive arguments.

> On that note I am happy that there was reasonable discussion on the bug
> report at https://bugs.gentoo.org/803878 but also somewhat disappointed
> that despite what seems like a lot of support for making the proposed
> fix, no one has actually stepped up and made that fix yet...

It looks like they have, now.  :-)

> > There doesn't appear to be anything better in emerge - I've looked but
> > not found an emerge action to unmerge specific packages only, apart from
> > --unmerge.  Why is there not a version of --unmerge which does safety
> > checks first?

> > The envisaged work flow seems to be doing things like --deselect,
> > followed by --depclean, praying that the latter isn't going to break the
> > system.  Given how much safer --unmerge is than --depclean, I don't
> > understand why the emerge man page puts a bold face warning right at the
> > start of --unmerge, but not on --depclean.


> I find this wording confusing and difficult to understand on your part.

> There is no option to unmerge specific packages only, using "--unmerge".
> I just tried it:

> ```
> # emerge --unmerge

> emerge unmerge can only be used with specific package names
> ```

> Oops? Your claims are totally invalid.

> I am nitpicking about this for an extremely good reason. Since --unmerge
> requires you to *specify the package name* (and since you have used it a
> lot, you surely know this fact) I don't think it should come as a shock that

> ```
> # emerge --depclean CAT/MYPKG
> ```

> also works. And, lo and behold -- it is a version of --unmerge that
> unmerges specific packages only, which does safety checks first.

OK, thanks.  I didn't know that.  The emerge man page section for
--depclean is far from clear on the point.  Looking at it more closely,
it doesn't mention giving it arguments until the very last subsidiary
paragraph.  It could, for example, start with "WITHOUT ARGUMENTS, cleans
the system by removing packages that are ....".  And it could replace
that useless weasel phrase "associated with" with "dependencies of".

It could also warn users that their system packages are not protected
against removal in certain circumstances.

It could correct the error where it says "Packages that are part of the
world set will always be kept.".  Earlier on on the man page it defines
@world to be the amalgam of @selected, @system, and @profile.  Despite
the reassuring words, --depclean wants to delete nano and openrc (still),
which are part of @world.

> This is also how I use --depclean by the way. I generally never depclean
> all packages, I take a look at what "emerge --depclean --pretend"
> suggests can be depcleaned and then decide whether I want to selectively
> depclean some of them by name.

It seems that we are in violent agreement on this, as well as on masking
the wayland user flag.

> I will say that I wish --depclean accepted glob patterns which would
> then match only on packages which are eligible for default-depcleaning.
> I have a small awk script that processes the output of "emerge -cpq" to
> select packages that aren't required by @world which match specific
> patterns such as language-specific categories for libraries, so e.g. I
> can depclean "all dev-perl stuff unless another package needs it"...

.... and we also agree that --depclean is not perfect.  ;-)

> >> The emerge manpage warns you against using --unmerge for good reason.

> > But doesn't state that reason or give a workable alternative.  Saying it
> > can remove important packages is unhelpful if it doesn't give an
> > alternative which can't.

> > My current workflow for clearing out orphaned packages is to do emerge
> > -p --depclean, then use emerge --unmerge on those packages listed which
> > aren't critical system packages or needed application programs.


> ... again, it literally says to use --depclean, but I'm increasingly
> getting the feeling that you are not *aware* that --depclean accepts
> package names.

I wasn't, no.  I am now.

> I find this odd, since the manpage entry for --depclean says it pretty
> clearly:

> """
> Depclean serves as a dependency aware version of --unmerge. When given
> one or more atoms, it will unmerge matched packages that have no reverse
> dependencies.
> """

As mentioned above, that is an obscure subsidiary paragraph, inaccessible
to somebody who is scanning the man page looking for what they want, as
opposed to somebody who is explicitly interested in everything about
--depclean.

> > --depclean is too clumsy.  It assumes I want to unmerge nano, for reasons
> > which are surely not intended UI, but just because that's the way it was
> > implemented.  I think a --ask flag only asks whether to delete all listed
> > packages or none, not each package individually.  What I would prefer is
> > an interface by which _I_ specify which packages are to be removed.


> Implementing a per-package ask seems like it would be challenging, as it
> would have to go back and recalculate which packages can still be asked
> about if you respond "no" to some package that other packages depend on.

OK.

> It does sound like an interesting idea though -- maybe worth submitting
> a feature request?

Maybe.

Thanks for all the helpful information over the last month or so.  I've
learnt a lot.

> -- 
> Eli Schwartz

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: [gentoo-user] --depclean and openrc [Was: Wayland! Beware of!]

[Eli Schwartz]

[-- Attachment #1.1: Type: text/plain, Size: 2318 bytes --]

On 10/27/24 6:52 PM, Alan Mackenzie wrote:
> OK, thanks.  I didn't know that.  The emerge man page section for
> --depclean is far from clear on the point.  Looking at it more closely,
> it doesn't mention giving it arguments until the very last subsidiary
> paragraph.  It could, for example, start with "WITHOUT ARGUMENTS, cleans
> the system by removing packages that are ....".  And it could replace
> that useless weasel phrase "associated with" with "dependencies of".


I see what you mean. The --depclean flag (and --unmerge as well) is
listed in the section for "action"s. depclean isn't an *option* such as
--ask / --color / --jobs / --verbose / etc.

And, the synopsis states that all *actions* allow specifying optional
atoms / sets / etc at the same time.

This isn't clear from reading the individual documentation on an action,
but I'm not sure what a solution here might look like.


> It could also warn users that their system packages are not protected
> against removal in certain circumstances.
> 
> It could correct the error where it says "Packages that are part of the
> world set will always be kept.".  Earlier on on the man page it defines
> @world to be the amalgam of @selected, @system, and @profile.  Despite
> the reassuring words, --depclean wants to delete nano and openrc (still),
> which are part of @world.


@world is an alias expansion (it expands its contents, in this case,
@selected @system @profile).

@system is also an alias expansion -- it expands the profile-based list
of atoms for system.

Moving beyond that, nano and openrc aren't an *expansion* of @world, but
they are an RDEPEND of atoms (virtual/*) that are expanded from @world.

The emerge documentation says that packages that are part of the world
set -- i.e. they are expanded from @world -- will be kept. It doesn't
say that their dependencies will be kept (there are arguments about why
this is the portage design, but this discussion is less about whys and
more about whether the documentation is correct, so that's what I will
address).

I don't really see that part of the documentation as being in error.
Although I suppose I also don't see any harm in rewording it for
additional clarity. I'm not sure exactly how to reword it...


-- 
Eli Schwartz

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 236 bytes --]