Alan Mackenzie wrote: > Hello, Neil. > > On Sun, Jul 25, 2021 at 10:03:44 +0100, Neil Bothwick wrote: >> On Sat, 24 Jul 2021 21:01:34 +0000, Alan Mackenzie wrote: >>>>> 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. >> They are, @system is a set of packages and nothing it it will be >> depcleaned. However, openrc is not part of @system, the virtual is. > Ah, that's it. So we have critical system packages which aren't part of > @system. I think openrc is a critical system package. > >>>> 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. >> That is possible, but it is also possible that this is entirely down to >> you installing things outside of portage and handling their dependencies >> manually, creating unwanted side-effects like this. > Quite the contrary. If I'd've stuck to the daemontools I installed from > a tarball, this whole thing wouldn't have happened. It's BECAUSE I > switched to using the portage version that this danger reared its ugly head. > >>> 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. >> It did that because you have another suitable editor installed. I don't >> like nano so I'm happy to install something else that satisfies >> virtual/editor and let depclean get rid of nano, knowing that it won't do >> it unless I already have a suitable alternative installed. >>> 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. >> I feel it's more a case of Gentoo being a system for those that >> understand what they are doing with the system - with great power comes >> great responsibility and all that. > That feels needlessly patronising, Neil. I fear the Gentoo maintainers > will take the same attitude. Not only can the user shoot himself in the > foot, but it's Gentoo that provides the gun, innocently wrapped, with a > "press here" direction on the packaging above a hidden trigger. Nobody > accepts any responsibility for preventing accidents. > > The implication of what you say is that nobody should use portage > without understanding every last intricate detail of it. This doesn't > feel reasonable. > > Nobody but me seems to see anything wrong with all this. It's one thing > saying users should look after themselves, but surely it's quite another > thing to provide an obsure mechanism where one's one keypress away from > destroying ones system. > > I'm quite a bit less enthusiastic about Gentoo than I was a few days > ago. > >> -- >> Neil Bothwick >> Caution, an incorrigible punster - don't incorrige.
The point is the same as it always has been. If you install a package outside of portage's knowledge, it is on you to make sure any dependencies are installed and to update the package itself. Surely you don't expect emerge/portage to know you installed a package outside its knowledge and to keep things it depends on by some sort of magic. When a user updates using emerge/portage, it can only go by what it knows. It can't assume something it has no knowledge of. This is why I mentioned creating a ebuild for your mail program and using emerge to install it. In the ebuild will be what that software depends on. That puts emerge/portage in the know that certain things are needed and not to remove them. Unless you do that, or add needed packages to the world file, emerge/portage will want to remove things it feels are not needed based on what it knows. To be honest, this is expected behavior. It's the whole point of --depclean. In short, this is expected behavior. If it didn't work this way, then I'd say there is a bug that needs to be addressed. I might add, this is why I try to never install anything outside of using emerge/portage. It always leads to problems like this. At the moment, I can think of nothing that is installed on my system that isn't done by emerge/portage. Even old software that is dying is still known to emerge/portage. When it no longer works, I'll unmerge it and move on to other software. At the moment, Gnome-mplayer comes to mind on that. Thing is, emerge/portage is aware of every single package installed on my system. At least you have two options that should correct the problem. Make a ebuild or add the needed packages for your mail program to the world file. Either way should make things work. I'd think the ebuild is the best way but one has to write the ebuild. Adding the needed packages to world file is easiest but could change if you upgrade the mail program. Hope you find one of those a good option. Dale :-) :-)
