Re: [gentoo-user] --depclean wants to remove openrc. Yikes!
Alan Mackenzie wrote: > Hello, Dale. > > On Sat, Jul 24, 2021 at 10:03:52 -0500, Dale wrote: > >> Maybe qmail needs a USE flag to pull in daemontools? > I'm actually using s/qmail, tarball direct from its maintainer, since > there's no ebuild for it. Originally, I had daemontools from the same > place, until I discovered there was an ebuild for it. > > Ahhh. That could be a issue when filing a bug. When using something without the package manager installing it, it usually leaves you on your own. The easiest thing may be to just add daemontools to your world file and leave it at that. The maintainer may have another solution but I'm suspecting not. Another option, create a ebuild for your mail program and put it in your overlay. Then you can use emerge to install your mail program so that emerge knows the dependencies it needs, including daemontools. As it is, it doesn't even know you have the mail program there. Sort of hard for emerge/portage to know you need a tool kept around. A ebuild for it and using emerge to install it would fix that. Maybe a USE flag or just a plain hard requirement for daemontools. Just a thought. Someone else may have a better hammer to fix this problem. Dale :-) :-)
Re: [gentoo-user] --depclean wants to remove openrc. Yikes!
Hello, Dale. On Sat, Jul 24, 2021 at 10:03:52 -0500, Dale wrote: > Alan Mackenzie wrote: > > I'm considering submitting a bug to bugs.gentoo.org, requesting that > > _all_ installed packages satisfying a virtual get kept. There is surely > > something wrong when somebody who just wants to be a user (me) has to > > read .ebuild files to get normal things done. > If you can, I'd recommend trying to reach out to the maintainer to see > if that is expected behavior. It could be that that is the way it is > supposed to work. If that is so tho, I find it odd. I find it infuriating when ordinary innocent use of something like emerge can totally break a system. > Maybe qmail needs a USE flag to pull in daemontools? I'm actually using s/qmail, tarball direct from its maintainer, since there's no ebuild for it. Originally, I had daemontools from the same place, until I discovered there was an ebuild for it. > Maybe something else needs changing. I'd start by reaching out to the > maintainer. I guess a bug report would be considered reaching out but > a email may also work as well. Thanks, I submitted a bug report. I think it's a bug in emerge. I've got a nasty feeling there isn't enough sympathy for non-experts for that bug to go anywhere, but we'll see. > Just my thoughts. May not be worth much. ;-) > Dale > :-) :-) -- Alan Mackenzie (Nuremberg, Germany).
Re: [gentoo-user] --depclean wants to remove openrc. Yikes!
Hello again, Rich. On Sat, Jul 24, 2021 at 10:58:55 -0400, Rich Freeman wrote: > On Sat, Jul 24, 2021 at 10:46 AM Alan Mackenzie wrote: > > On Sat, Jul 24, 2021 at 10:14:20 -0400, Rich Freeman wrote: > > > On Sat, Jul 24, 2021 at 9:47 AM Alan Mackenzie wrote: > > > > So in these virtual packages, it seems by default the _last_ mentioned > > > > package in a || ( ... ) construct is the one --depclean keeps. It all > > > > has the feeling of things not having been properly thought through. > > > I'm not sure what the default is - most likely PMS just requires that > > > one of them be kept. > > PMS? Part of emerge? > Package Manager Specification. Specifically: > https://projects.gentoo.org/pms/8/pms.html#x1-760008.2.3 Ah, thanks! > All it requires is that one be present. Portage can use whatever > behavior it wishes to decide which to keep (assuming all installed > packages have their deps). > > It seems it's insisting on removing all packages but one which satisfy a > > virtual. Maybe that is unwise, and it should keep _all_ such packages > > which are currently installed. > Well, the whole point of an any-of dependency is to only require one > of them. Why force packages to stick around if they aren't needed? I would say all packages in @system _are_ needed, unless the user explicitly says otherwise. > Now, whether daemontools actually should satisfy the dependency I > don't want to comment on without doing more research. Surely though > there is little point in having openrc and systemd and runit on the > same system unless the user explicitly wants this (and if they do they > can just stick them in @world). The user might be switching between them, doing comparisons. (No, I don't know if this is practical.) I don't know either whether it's practical to boot Gentoo with just daemontools. But there are use cases which require both openrc and daemontools on the same system, so there's something not quite right about the service-manager ebuild, or emerge. > > I'm considering submitting a bug to bugs.gentoo.org, requesting that > > _all_ installed packages satisfying a virtual get kept. There is surely > > something wrong when somebody who just wants to be a user (me) has to > > read .ebuild files to get normal things done. > I'd be shocked if that went anywhere. I'd think the better solution > would be to have some kind of USE flag that tells daemontools whether > it is used as an actual service manager or not, though that has its > own issues (changing that state shouldn't require rebuilds/etc, but it > would). I think that would be solving the wrong problem. The fact is, it is easy, far too easy, to shoot yourself in the foot here. As well as openrc, --depclean also wanted to remove nano (the editor) for the same reason. That might be serious for some people. I have, in fact, submitted a bug on the "shoot yourself in the foot" problem. So far it's got one reply which (possibly wilfully) misunderstood the intent of the report, and said, much like you did "add daemontools to @world and the problem's solved". Maybe the answer is to regard --depclean as a tool for experts only, since it is capable in ordinary innocent use of rendering a system unusable. > In any case, you probably should have a chat with the daemontools > maintainer. I doubt the portage team would consider doing something > like this as some kind of universal policy. It would impact hundreds > of things that have any-of dependencies. OK. The suggestion I made in my bug report was that @system packages should be protected, much like @world packages are already. I don't see the rationale in protecting @world, but not the more important @system. > -- > Rich -- Alan Mackenzie (Nuremberg, Germany).
Re: [gentoo-user] --depclean wants to remove openrc. Yikes!
Alan Mackenzie wrote: > > I'm considering submitting a bug to bugs.gentoo.org, requesting that > _all_ installed packages satisfying a virtual get kept. There is surely > something wrong when somebody who just wants to be a user (me) has to > read .ebuild files to get normal things done. > > If you can, I'd recommend trying to reach out to the maintainer to see if that is expected behavior. It could be that that is the way it is supposed to work. If that is so tho, I find it odd. Maybe qmail needs a USE flag to pull in daemontools? Maybe something else needs changing. I'd start by reaching out to the maintainer. I guess a bug report would be considered reaching out but a email may also work as well. Just my thoughts. May not be worth much. ;-) Dale :-) :-)
Re: [gentoo-user] --depclean wants to remove openrc. Yikes!
On Sat, Jul 24, 2021 at 10:46 AM Alan Mackenzie wrote: > > On Sat, Jul 24, 2021 at 10:14:20 -0400, Rich Freeman wrote: > > On Sat, Jul 24, 2021 at 9:47 AM Alan Mackenzie wrote: > > > > So in these virtual packages, it seems by default the _last_ mentioned > > > package in a || ( ... ) construct is the one --depclean keeps. It all > > > has the feeling of things not having been properly thought through. > > > I'm not sure what the default is - most likely PMS just requires that > > one of them be kept. > > PMS? Part of emerge? Package Manager Specification. Specifically: https://projects.gentoo.org/pms/8/pms.html#x1-760008.2.3 All it requires is that one be present. Portage can use whatever behavior it wishes to decide which to keep (assuming all installed packages have their deps). > It seems it's insisting on removing all packages but one which satisfy a > virtual. Maybe that is unwise, and it should keep _all_ such packages > which are currently installed. Well, the whole point of an any-of dependency is to only require one of them. Why force packages to stick around if they aren't needed? Now, whether daemontools actually should satisfy the dependency I don't want to comment on without doing more research. Surely though there is little point in having openrc and systemd and runit on the same system unless the user explicitly wants this (and if they do they can just stick them in @world). > I'm considering submitting a bug to bugs.gentoo.org, requesting that > _all_ installed packages satisfying a virtual get kept. There is surely > something wrong when somebody who just wants to be a user (me) has to > read .ebuild files to get normal things done. I'd be shocked if that went anywhere. I'd think the better solution would be to have some kind of USE flag that tells daemontools whether it is used as an actual service manager or not, though that has its own issues (changing that state shouldn't require rebuilds/etc, but it would). In any case, you probably should have a chat with the daemontools maintainer. I doubt the portage team would consider doing something like this as some kind of universal policy. It would impact hundreds of things that have any-of dependencies. -- Rich
Re: [gentoo-user] --depclean wants to remove openrc. Yikes!
Hello, Rich. On Sat, Jul 24, 2021 at 10:14:20 -0400, Rich Freeman wrote: > On Sat, Jul 24, 2021 at 9:47 AM Alan Mackenzie wrote: > > So in these virtual packages, it seems by default the _last_ mentioned > > package in a || ( ... ) construct is the one --depclean keeps. It all > > has the feeling of things not having been properly thought through. > I'm not sure what the default is - most likely PMS just requires that > one of them be kept. PMS? Part of emerge? It seems it's insisting on removing all packages but one which satisfy a virtual. Maybe that is unwise, and it should keep _all_ such packages which are currently installed. > If daemontools (or something that depends on it) is in your @world > that would explain why openrc was selected for removal. OK, that solves the mystery, thanks. > I don't know enough to comment on whether daemontools is a substitute > for openrc. My first complete guess would be that it could either be > used in addition to openrc or on its own. I've only ever used it as part of qmail (the mail transport program), never on its own. I'm loathe to mess around with it, since my email depends on it. But from what I remember about daemontools, it probably could be used as an alternative to openrc, I just don't envisage anybody wanting to do it, though. > Busybox can be a substitute for sysvinit or udev though most people > who have it installed probably don't intend for it to be used that > way. You could have that conversation with the maintainer. I'm considering submitting a bug to bugs.gentoo.org, requesting that _all_ installed packages satisfying a virtual get kept. There is surely something wrong when somebody who just wants to be a user (me) has to read .ebuild files to get normal things done. > -- > Rich -- Alan Mackenzie (Nuremberg, Germany).
Re: [gentoo-user] --depclean wants to remove openrc. Yikes!
On Sat, Jul 24, 2021 at 9:47 AM Alan Mackenzie wrote: > > So in these virtual packages, it seems by default the _last_ mentioned > package in a || ( ... ) construct is the one --depclean keeps. It all > has the feeling of things not having been properly thought through. > I'm not sure what the default is - most likely PMS just requires that one of them be kept. If daemontools (or something that depends on it) is in your @world that would explain why openrc was selected for removal. I don't know enough to comment on whether daemontools is a substitute for openrc. My first complete guess would be that it could either be used in addition to openrc or on its own. Busybox can be a substitute for sysvinit or udev though most people who have it installed probably don't intend for it to be used that way. You could have that conversation with the maintainer. -- Rich
Re: [gentoo-user] --depclean wants to remove openrc. Yikes!
Hello, Neil. On Wed, Jul 21, 2021 at 21:27:05 +0100, Neil Bothwick wrote: > On Wed, 21 Jul 2021 22:13:50 +0200, tastytea wrote: > > > emerge included openrc (the only version of it on my system) in the > > > packages it planned to remove. It was kind enough to give me a > > > warning that this "might" do bad things, but I was somewhat shocked > > > to see it there at all. I might have accidentally typed 'y' instead > > > of 'n'. > > > Maybe the program wants revenge at me executing so seldomly. Or > > > something like that. > Well, it would help if you ran it more often. > > > But now, my question is how can I trust --depclean even a little bit > > > after that? Do I have to go through all the package versions, > > > manually removing the obsolete ones? There are several hundred. :-( > > I'm not sure why it would want to remove openrc, as far as I know it > > should be part of the @system set unless you're on a systemd profile. > It's the first dependency of virtual/system-manager, which in turn is > part of @system. I don't see why it would be removed unless you have > something else installed that satisfies the virtual , such as systemd or > runit. The virtual/service-manager ebuild looks like: ; # Copyright 1999-2021 Gentoo Authors # Distributed under the terms of the GNU General Public License v2 EAPI=7 DESCRIPTION="Virtual for various service managers" SLOT="0" KEYWORDS="~alpha amd64 arm arm64 hppa ~ia64 ~m68k ~mips ppc ppc64 ~riscv ~s390 sparc x86 ~x64-cygwin ~amd64-linux ~x86-linux ~ppc-macos ~x64-macos ~sparc-solaris ~sparc64-solaris ~x64-solaris ~x86-solaris ~x86-winnt" IUSE="kernel_linux" RDEPEND=" prefix-guest? ( >=sys-apps/baselayout-prefix-2.2 ) !prefix-guest? ( || ( sys-apps/openrc kernel_linux? ( || ( sys-apps/systemd sys-process/runit virtual/daemontools < ) ) ) )" ; Maybe virtual/daemontools is what's doing it. I have sys-process/daemontools-0.76-r8 installed, and this ebuild satisfies virtual/daemontools. However daemontools is NOT (necessarily) an alternative to openrc, but a supplementary utility. (I need it for running a qmail variant.) So, maybe having daemontools in virtual/service-manager is a bug. Also, why is --depclean keeping the _last_ installed package which satisfies a virtual rather than the _first_ package which does? I thought only a single package satisfying a virtual was allowed. Maybe I used some sort of forcing flag to get daemontools installed, I can't remember, and there's nothing about this in my notes. I've got a similar situation with virtual/editor, where I've got vim installed, and --depclean wants to remove nano, but is warning me against it. So in these virtual packages, it seems by default the _last_ mentioned package in a || ( ... ) construct is the one --depclean keeps. It all has the feeling of things not having been properly thought through. > > You can record it in your @world set with `emerge --select --noreplace > > sys-apps/openrc`. That should prevent accidental removals. > It would, but it doesn't address the issue of why portage wants to remove > it. > -- > Neil Bothwick > mandelbug /man'del-buhg/ n. > [from the Mandelbrot set] A >bug whose underlying causes are so complex and obscure as to make >its behavior appear chaotic or even non-deterministic. This term >implies that the speaker thinks it is a Bohr bug, rather than >a heisenbug. See also schroedinbug. -- Alan Mackenzie (Nuremberg, Germany).
