| 1 |
On Mon, Oct 12, 2009 at 11:39 AM, Victor Ostorga <vostorga@g.o>wrote: |
| 2 |
|
| 3 |
> |
| 4 |
> I don't know the history about init systems category, but obviously is |
| 5 |
> necessary to stablish a category into which init systems should live |
| 6 |
> happy forever (sys-init ? app-init? foobar?). |
| 7 |
> |
| 8 |
> |
| 9 |
I don't know what you want to call it, "sys-init" perhaps. But it, and a |
| 10 |
number of other packages, e.g. sys-apps/util-linux (which includes mount and |
| 11 |
fsck), openrc, bash, udev, etc. belong in a "special" category for "packages |
| 12 |
which could prevent the system from booting or corrupt file systems" if the |
| 13 |
emerges do not work perfectly. I get hung up once or twice a year by |
| 14 |
semi-auto-emerging a package not realizing that it is a potential |
| 15 |
show-stopper that should be closely monitored (or which should require an |
| 16 |
immediate system reboot to see if it broke anything). In contrast, you |
| 17 |
could break any of the various X libraries, browsers, etc. and still have a |
| 18 |
system from which one could fall back/forward. |
| 19 |
|
| 20 |
Right now one only knows if an emerge is "N"ew or an "U"pgrade with little |
| 21 |
indication as to how badly it could go wrong. |
| 22 |
|
| 23 |
As far as I know there is no "critical packages" list (or class) which |
| 24 |
include those that are likely to create much bigger headaches than common |
| 25 |
emerge failures (for example this would include all executables used by the |
| 26 |
init/openrc processes) which under ideal circumstances would be part of a |
| 27 |
single package that could be compiled with a "static" option. |
| 28 |
|
| 29 |
Robert |
Archives