| Sysop: | Amessyroom |
|---|---|
| Location: | Fayetteville, NC |
| Users: | 43 |
| Nodes: | 6 (0 / 6) |
| Uptime: | 96:27:27 |
| Calls: | 290 |
| Files: | 904 |
| Messages: | 76,426 |
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.
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.
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
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.
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.
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ć
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.
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.
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.
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
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.
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
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.
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.
(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.
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.
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.
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
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?