| 1 |
On Sun, 25 Jul 2021 13:43:46 +0000, Alan Mackenzie wrote: |
| 2 |
|
| 3 |
> > It may be critical for *your* system ... :-) |
| 4 |
> |
| 5 |
> Just as systemd is for your system. If you'd installed daemontools you |
| 6 |
> would also have come within a keystroke of destroying your system, just |
| 7 |
> as I did, on attempting emerge --depclean. You would have received no |
| 8 |
> warning of any kind on installing the package, and there would be no |
| 9 |
> documentation brought to your attention about the potential catastrophe. |
| 10 |
|
| 11 |
This is a valid point, that appears to have been obscured by some of the |
| 12 |
discussions about the cause. As to whether it would render the system |
| 13 |
unbootable, I have no idea, would daemontools have taken care of that. |
| 14 |
|
| 15 |
It seems that Rich's suggestion has the most merit, add a USE flag to |
| 16 |
daemontools to indicate that it is intended to be your service manager, |
| 17 |
and have the virtual require that flag. Yes, it would require a |
| 18 |
one-off rebuild of daemontools for everyone with it installed, but the |
| 19 |
potential for breakage would be removed. |
| 20 |
|
| 21 |
If I had to allocate blame for this, I would say it is the virtual that |
| 22 |
is the cause of the problem. With the current setup, unmerging openrc is |
| 23 |
the only way for depclean to deal with it when you have daemontools in |
| 24 |
@world. |
| 25 |
|
| 26 |
|
| 27 |
-- |
| 28 |
Neil Bothwick |
| 29 |
|
| 30 |
Top Oxymorons Number 41: Good grief |
Archives