I have a bunch of systems that are all the same, with the same binaries. On 2 systems only, out of many, portage wants to remove system packages. I am not asking it to remove them, and its warning about it. Not sure where it is picking it up. Why just on these two, and not others that are for the most part identical of them. But not identical as in images or containers. Thus on 2 I have this issue and not others. I am not sure what the difference is, to cause the following to occur. Same profiles, USE flags, binaries, etc. Pretty odd emerge -qv --depclean ... net-misc/netifrc: 0.5.1 none none !!! 'sys-apps/openrc' (virtual/service-manager) is part of your system profile. !!! Unmerging it may be damaging to your system. sys-apps/openrc: 0.34.11 none none virtual/tmpfiles: 0 none none sys-apps/sysvinit: 2.88-r9 none none sys-apps/opentmpfiles: 0.1.3 none none All selected packages: =sys-apps/openrc-0.34.11 =virtual/tmpfiles-0 =sys-apps/opentmpfiles-0.1.3 =sys-apps/sysvinit-2.88-r9 =net-misc/netifrc-0.5.1 sys-apps/portage-2.3.19-r1::gentoo
It's normal that these are queued for removal if you have systemd. The warnings are a bug, more info in bug 375115 *** This bug has been marked as a duplicate of bug 375115 ***
I am NOT running Systemd but OpenRC....
Check what's satisfying the virtual with "portageq expand_virtual / virtual/service-manager", might be daemontools. If you're using openrc, you should add it to world to be safe.
That other bug does not seem related. That seems to be a different issue. In this case I am not using systemd. I never have. I have no USE flags for such. I have this system running on same binaries, USE flag, profile, etc as other systems also running OpenRC. All my systems run OpenRC. Thus I am at a loss why it is trying to remove a much needed very core system package. That will totally hose any system it is removed from. To me it seems like something MUST be different in these two servers for them to be trying to remove my only init stuff. I am not clear if it is a system issue, or some other larger bug in portage etc. It seems odd it would just be these two systems out of many 20+. They are all configured via ansible, using same binhost, etc. I cannot make any sense why it wants to remove those from 2 systems only. I can add them to my world files which will prevent removal, as a hack solution. Adding a file to world on 2 servers and not others is not a good approach. It seems like the wrong solution to the problem. I just checked all systems and none have any profile related package in world. Definitely not any of those being removed. I want to know why portage thinks they should be removed. With nothing replacing them, no alternative to some virtual. Not to mention the warning. It seems it knows its doing something wrong I did not request. Now if I did emerge -C openrc, etc. Then such warning would make sense. But not with a plain global emerge --depclean. Thus opening issue. These are profile installed packages, not user selected.
Find out what portage believes is satisfying virtual/service-manager.
(In reply to Ben Kohler from comment #5) > Find out what portage believes is satisfying virtual/service-manager. I believe its showing that in the error message. !!! 'sys-apps/openrc' (virtual/service-manager) is part of your system profile. It seems to know openrc is related to virtual/service-manager. # equery depends openrc * These packages depend on openrc: net-misc/netifrc-0.5.1 (>=sys-apps/openrc-0.15) virtual/service-manager-0 (!prefix ? sys-apps/openrc) $ emerge -pv service-manager [ebuild R ] virtual/service-manager-0::gentoo USE="(-prefix)" 0 KiB Maybe something is off with the profile or baselayout package? hardened/linux/amd64 (stable) Something is making it think openrc is not needed. Which then caries onto anything else brought in by that package.
Please check "portageq expand_virtual / virtual/service-manager" output. This will show what is actually satisfying the virtual. That it warns about openrc being part of the system profile, IS a bug, the bug I mentioned before. The bug is that it claims openrc is part of @system just because it is a POSSIBLE provider for virtual/service-manager, even though it is not *the preferred* provider. Find out what the preferred provider is.
(In reply to Ben Kohler from comment #7) > Please check "portageq expand_virtual / virtual/service-manager" output. > This will show what is actually satisfying the virtual. # portageq expand_virtual / virtual/service-manager sys-apps/openrc Seems like it has to be the preferred as it is the only.
Can you look in /usr/portage/virtual/service-manager/service-manager-0.ebuild and see if you have any of the other virtual providers installed?
The only other thing installed is from that ebuild is virtual/daemontools and sys-process/daemontools, brought in by qmail on mail servers. I removed and re-installed and did not get a warning. Those must be brought in by qmail not virtual/service-manager. I thought it might be those packages, but I have them on other mail servers that are not trying to remove openrc. It does seem this issue is specific to some of my mail servers. Really at a loss...
Well it doesn't particularly matter why daemontools was first installed, depclean is going to try to keep the minimal set of packages needed to satisfy all of @world & deps. So to me this seems perfectly legal/normal that depclean considers openrc unneeded, with the way the deps are structured now. I don't know why you cannot reproduce it on all machines which have daemontools. I wish daemontools were not part of that virtual at all, or at least would require an extra USE flag to be considered the system's sole service-manager. I think that idea has been discussed in some other bug somewhere...
daemontools should not matter to openrc as its part of that same dep chain. Though it should be requiring it as part of the system profile. Per service-manager RDEPEND=" prefix? ( >=sys-apps/baselayout-prefix-2.2 ) !prefix? ( || ( sys-apps/openrc kernel_linux? ( || ( sys-apps/systemd sys-process/runit virtual/daemontools ) ) ) )" I am not using prefix, so I hit the !prefix. Which there it seems odd to have an ||, openrc OR kernel_linux. Maybe that is wrong? Should it be like? RDEPEND=" prefix? ( >=sys-apps/baselayout-prefix-2.2 ) !prefix? ( sys-apps/openrc kernel_linux? ( || ( sys-apps/systemd sys-process/runit virtual/daemontools ) ) )" Which would mean no prefix, you MUST have openrc, but optional kernel_linux, and if you have that, you need one of the other optional things for kernel_linux. Which in my case would be daemontools or runit, or systemd. In fact looking at that more, I think the || for kernel_linux is for systemd, since its not available outside Linux. Which means its needs to get more complicated. Those others are likely also linux specific. I assume what is happening is its seeing kernel_linux USE flag set. So taking that path. Qmail brings in virtual/daemontools, and the virtual assumes that its satisfied per that. Which it is not. Seems like that would happen for all systems. All systems would be removing openrc if kenrnel_linux is set. But that may matter on the order they show up. In some programming file order is not always alphabetical. It might be resolving packages in a different order or something. Triggering that bad dependency path. Seems like that must be where the difference comes from or something. kernel_linux causing openrc to not be needed and removed. Since its one or the other. I would assume all my systems to have kernel_linux, not just the 2 exhibiting the problem. Thus order must explain why it wants to remove from just 2 mail servers and not all servers or all mail servers.
I get what they are after, systemd is linux specific, but needs to be some option between openrc and systemd. But putting systemd under the kernel_linux causes further issues. I think in my case that daemontools is there. Which I do not believe daemontools is a replacement for openrc. Thus that part of the chain is broken and likely same for sys-process/runit. If you have either daemontools or runit, plus kenrel_linux, then you do not need openrc per the package. That seems wrong. I think the ONLY time you do not need openrc is when you have systemd. Those are the only two real options.
I think it should be like this RDEPEND=" prefix? ( >=sys-apps/baselayout-prefix-2.2 ) !prefix? ( || ( sys-apps/openrc kernel_linux? ( sys-apps/systemd ) ) )" Not sure where those other 2 packages should be. But them being under kernel_lnux, I think is causing my problems. I can follow that path for sure.
> I think the ONLY time you do > not need openrc is when you have systemd. Those are the only two real > options. I don't think this premise is accurate. These other 2 pkgs CAN be used to replace openrc. The problem is that it's too easy to install these by accident when you DON'T plan to use them to replace openrc. That's why I've elsewhere proposed that we add some USE flag to daemontools (and maybe runit) so you have to explicitly opt into them being your service-manager replacement. Personally I'd be happy if only openrc & systemd were considered in this virtual, but some people ARE actually using the other options.
Many of our system virtuals are *too* flexible to be reliable for users, so users really need to add the specific packages that they want to the world file, for example: emerge --noreplace sys-apps/openrc
Ok, well at least we know where the problem is coming from. -prefix +kernel_linux, with daemontools installed == openrc not needed. That makes depclean think openrc is not needed. At the same time other things noticed it is needed, thus the warning. That also explains why systems without daemontools do not have this issue. It does not explain why some with it do not try to remove openrc. Other than different package order in resolution. You maybe correct and only clean way is a USE flag for daemon tools and runit. I do not see any means to work it out with conditionals. Once daemontools or runit is installed, that makes portage think openrc is not needed. I would not say the virtual is to flexible as broken. You can have bad paths out of the box. I think the USE flag or something for others makes more sense. I would assume in most like 99% of the time, people are running either openrc or systemd. Those running runit or daemontools without openrc or systemd, must be a minority. I would think they could handle a USE flag. Rather than having to run around and pull in specific packages or tell it which you want. Virtuals IMHO should have a valid path without the user having to do anything. OR portage should know that daemontools is a dependency of qmail, NOT service-manager. qmail is bringing in daemontools, not virtual-manager. Thus not sure it should be considered a provider for a package that did not bring it in. More so we are talking system vs world packages. Qmail being a world/user installed package. Portage should not try to consider user installed packages like that to be providers for system stuff. If I added daemontools to world, then sure portage should use that over openrc. But if daemontools is coming in as a dependency of another package. IMHO that should not be treated the same as the user pulling in daemontools as a replacement for openrc. Or to put it another way, 50% of the time, portage knows it should not remove the package. The output from --depclean, warns on removing a system package. Thus that half of the time, it knows its part of system. But the other half, where its collecting packages to be removed. That part fails, and it assumes openrc is not needed when it sees daemontools. If portage never said anything about openrc being a provider for virtual-manager, because daemontools was installed. That would make sense, and it would not be 50/50. Portage in this case knows its doing the wrong thing. Thus half is incorrect, and half is correct :)
(In reply to William L. Thomson Jr. from comment #17) > Ok, well at least we know where the problem is coming from. > > -prefix +kernel_linux, with daemontools installed == openrc not needed. > > That makes depclean think openrc is not needed. At the same time other > things noticed it is needed, thus the warning. No. That "other things noticed it is needed" is wrong. The way it warns about removal, is bug 375115. It's the same as when you install vim and nano becomes depcleanable. It will warn about nano removal, but this is a bug, nano is NOT needed by other pkgs.
I think something does need fixed here, but please read up on that other bug about the erroneous warning regarding virtuals in @system. Don't let that erroneous warning muddy the waters here.
(In reply to William L. Thomson Jr. from comment #17) > If I added daemontools to world, then sure portage should use that over > openrc. But if daemontools is coming in as a dependency of another package. > IMHO that should not be treated the same as the user pulling in daemontools > as a replacement for openrc. The thing is, portage must remove redundant packages. If virtual/service-manager is satisfied without openrc, and nothing else requires openrc, then portage *must* remove openrc. It doesn't matter *why* daemontools was installed. So, if you need openrc then you *must* add it to @world, since virtual/service-manager is unreliable.
(In reply to Zac Medico from comment #20) > (In reply to William L. Thomson Jr. from comment #17) > > If I added daemontools to world, then sure portage should use that over > > openrc. But if daemontools is coming in as a dependency of another package. > > IMHO that should not be treated the same as the user pulling in daemontools > > as a replacement for openrc. > > The thing is, portage must remove redundant packages. If > virtual/service-manager is satisfied without openrc, and nothing else > requires openrc, then portage *must* remove openrc. It doesn't matter *why* > daemontools was installed. So, if you need openrc then you *must* add it to > @world, since virtual/service-manager is unreliable. Then the rule should be users should add packages they need to world regardless of in profile or a virtual. Also that virtuals may not work out of the box, since dependencies of other packages can change virtuals installed. No way to have usable defaults, because any package installed may change virtuals default, via depdencies. Not a package explicitly installed by the user. It is treating deps of world packages like they are also in world when they are not. That seems a bit wonky... Virtuals may make the package maintainers life easier, but its having the opposite effect on users. Seems like something eselect should be handling or something rather than relying on packages. Since they may end up on the system via different means, and treated differently. If openrc, runit, and daemontools are installed. Which does portage use? Would my system still boot? In those other bugs, they still had a working editor and did not break their systems. In this case, pretty sure the servers would not boot without openrc. Also seems like this goes back many years, the other reference bug is more interesting. Like this comment about redundant packages. I see myself thinking allot of the comments Paco was making. https://bugs.gentoo.org/370295#c33 Taken into consideration with this one about the order. Which makes sense that user WORLD overrides system, and profile. https://bugs.gentoo.org/370295#c40 World makes sense, IF a provider exists in world. If a provider does not, explicitly listed in world, not a dep. It should not assume a dependency of a world package is a provider. Just as if a user added it to world. If that package itself is not in world, it is not a provider. Just as you want me to add the one I do want to world. It is assuming the one brought in by a dep is in world. That seems off. If I added runit or daemontools to world, that should take over openrc. But if those came in as a dep of something else in world. That should not IMHO replace openrc. That seems like a sure way to get into trouble with stuff. Seems people have been having problems with this for years, and even requires a faq entry. https://wiki.gentoo.org/wiki/Project:Portage/FAQ#Why_does_emerge_--depclean_sometimes_remove_system_packages.3F Seems like the more you have to instruct people, the more the current way is not ideal. It seeming to some what defeat the purpose. Or make it so nothing is defaulted, and all the user must select a provider for any virtual. That is essentially what is happening here, just after the fact. Either virtual should resolve with defaults, and no providers added to world. Or they should all require the user to choose. Trying to do both creates situations like this. Plus double rules, sometimes you need to specify which you want, other times not can rely on virtual defaults. At least not till something else shows up providing that. Which may creep in as a dep vs something you added to world explicitly. Seems nasty all around...
Its all clear now and I can work around. Feel free to leave open or not. This some what goes along with stuff I was saying in another ticket. Regarding a warning when removing dependencies. https://bugs.gentoo.org/624630 Like I do not get any warnings on daemontools if I remove that. Despite it being a virtual provider, and a dependency. It should be prevented as a dependency. Or warning like removing openrc generates a warning. daemontools is a provider. I assume I do not get a warning about removing it from system, because its seeing openrc. But I do get a warning about opernc, despite daemontools. So from that angle also seems off. Seem removing either daemontools or openrc should generate a warning. But only 1 does, openrc. I assume because daemontools is brought in as a dep. Thus no warning because it knows its a dep not part of the base system/profile. It confuses itself... :)
(In reply to William L. Thomson Jr. from comment #22) > Like I do not get any warnings on daemontools if I remove that. Despite it > being a virtual provider, and a dependency. It should be prevented as a > dependency. Or warning like removing openrc generates a warning. daemontools > is a provider. I assume I do not get a warning about removing it from > system, because its seeing openrc. But I do get a warning about opernc, > despite daemontools. So from that angle also seems off. Seem removing either > daemontools or openrc should generate a warning. But only 1 does, openrc. I > assume because daemontools is brought in as a dep. Thus no warning because > it knows its a dep not part of the base system/profile. The reason for this is that the warning uses the expand_new_virt function which selects the preferred virtual provider based on the order that they are listed in the virtual dependencies. Since sys-apps/openrc is the preferred choice based on this order, if always warns when removing openrc. Since daemontools is the least preferred choice, if will only warn for daemontools if no other provider is installed. My preference would be to eliminate the warning message entirely, but we kept it until now under the assumption that it might help some people (some people still remove openrc accidentally).
Seems like something should be done so wanted stuff default is not removed, short of explicitly adding. I can see the perspective on the warning. I feel the opposite, it is good it is there, and should be the same for dependencies. It makes sense and I understand why it is happening. Just not really a pleasant user experience. Then again I can always maintain my own virtual and/or profiles, and eliminate the problem that way. Just seems like there should be a better way for all this. It makes me like virtuals less and less... Not really any easy solution for all. Still need to experiment with booting under runit and daemontools. I guess those are drop in replacements for openrc. If those are not drop in replacements, then that makes a difference. If they are, then just have to go with adding one to world, profile, or custom virtual in overlay.
I found this bug as I encountered the same situation, and luckily I can affort to replace netqmail with ssmtp on this particular computer. However, the behaviour points to a flaw in portage's design on the issue, namely the situation of 1) using openrc as the primary init system and 2) using netqmail as MTA, which brings in daemontools. Note that the host where this situation occured lived with openrc+netqmail for around ~15 years before portage mistakenly wanted to uninstall openrc during depclean, so this is a new undesired effect of some changes inside portage. I hope you will find a solution that satisfies both packages.
