| 1 |
Hello, Neil. |
| 2 |
|
| 3 |
On Sun, Jul 25, 2021 at 16:40:23 +0100, Neil Bothwick wrote: |
| 4 |
> On Sun, 25 Jul 2021 13:43:46 +0000, Alan Mackenzie wrote: |
| 5 |
|
| 6 |
> > > It may be critical for *your* system ... :-) |
| 7 |
|
| 8 |
> > Just as systemd is for your system. If you'd installed daemontools you |
| 9 |
> > would also have come within a keystroke of destroying your system, just |
| 10 |
> > as I did, on attempting emerge --depclean. You would have received no |
| 11 |
> > warning of any kind on installing the package, and there would be no |
| 12 |
> > documentation brought to your attention about the potential catastrophe. |
| 13 |
|
| 14 |
> This is a valid point, that appears to have been obscured by some of the |
| 15 |
> discussions about the cause. As to whether it would render the system |
| 16 |
> unbootable, I have no idea, would daemontools have taken care of that. |
| 17 |
|
| 18 |
And this is the main point of my complaint - the surprise, the shock, and |
| 19 |
the innocence (as in opposite of guilty, not of wordly-wise) of the |
| 20 |
victims. They have done nothing but installing a package in the normal |
| 21 |
way. daemontools can only boot a system if it's been configured to do |
| 22 |
so. That involves writing entries into /etc/inittab. |
| 23 |
|
| 24 |
The number of people who would lose their systems by this mechanism is |
| 25 |
likely very small, but that loss would probably involve a |
| 26 |
re-installation. I mean all a victim has to go on is the fact that his |
| 27 |
machine won't boot, combined with a memory of having run emerge |
| 28 |
--depclean the night before. |
| 29 |
|
| 30 |
My guess (for which I have little basis) would be that daemontools is |
| 31 |
used more as part of the various qmail variants rather than as the prime |
| 32 |
init system. I don't recall anybody on this list using d. rather than o. |
| 33 |
or s. as their main init system. In fact, I wasn't even aware it was |
| 34 |
possible, before looking it up on Wikipedia this afternoon. |
| 35 |
|
| 36 |
> It seems that Rich's suggestion has the most merit, add a USE flag to |
| 37 |
> daemontools to indicate that it is intended to be your service manager, |
| 38 |
> and have the virtual require that flag. Yes, it would require a |
| 39 |
> one-off rebuild of daemontools for everyone with it installed, but the |
| 40 |
> potential for breakage would be removed. |
| 41 |
|
| 42 |
Another idea I had today is to have two packages, daemontools and |
| 43 |
daemontools-init, which would be identical, apart from the fact that only |
| 44 |
the second of these would satisfy virtual/service-manager. |
| 45 |
|
| 46 |
> If I had to allocate blame for this, I would say it is the virtual that |
| 47 |
> is the cause of the problem. With the current setup, unmerging openrc is |
| 48 |
> the only way for depclean to deal with it when you have daemontools in |
| 49 |
> @world. |
| 50 |
|
| 51 |
I can't help feeling that maybe portage has become too complicated. |
| 52 |
|
| 53 |
> -- |
| 54 |
> Neil Bothwick |
| 55 |
|
| 56 |
> Top Oxymorons Number 41: Good grief |
| 57 |
|
| 58 |
-- |
| 59 |
Alan Mackenzie (Nuremberg, Germany). |
Archives