Re: Possible ITP: Rescue Package
According to Dale Scheetz:
> On Mon, 26 Jul 1999, Fabien Tassin wrote:
> > Well, it would be nice to have a rescue package too (optional or recommended).
> Probably "Extra".
I've re-read section 2.2 of Debian Policy and "Extra" is probably the better
choice (even if the quote in "important" will be heard if we forget
> > This will let people choose between rescue disk or direct rescue.. or both.
> > Unfortunatly, I have nearly zero free time to do this myself :(
> As I'm already working on a semi-related problem, maybe I can do this.
Great !! :)
> What you seem to be asking for, is a collection of utility programs that
> are static linked for use in a hosed system. All of these program exist in
> current packages, but only need to be compiled differently and collected
> into one binary package. This is the part I am already working on.
> In addition, if this is going to act like a "normal" Debian package, it
> must install these programs somewhere besides the locations of their
> dynamicly linked counterparts, and still be accessible within the
> "crashed" system. A system similar to update alternatives could be used to
> "replace" the dynamic tools with their static counterparts, but I don't
> think this is a good idea, because in a normal system you don't want
> little tools running around with big memory footprints.
> The desire is to have the tools execute easily, so long path names for
> their location is not desirable. An alternate method would add a simple
> short string to the front of the command names, so vi would becom rsqvi,
> cp would become rsqcp, etc...
FHS seems to use /sbin/ and a single 's' prefix...
This can be a trouble: sh->ssh ash->sash, cp->scp... but if we add this
prexif only to tools that are already in /sbin, it could work.
/sbin/ldconfig (already static)
/sbin/init (can we rename it ?)
/sbin/sulogin (should be static in any case, IMO)
> Utilities using this naming convention could easily go into /sbin and /bin
> although they would still need a full pathname when your path is broken.
> The main question is: "What constitutes a reasonable list of utilities?"
> I would suggest that we start with:
> nvi/vim/elvis (someone else has to fight this one out)
ash is the better candidate. A simple sh could be enough but
we have no such beast (for now). [ what about pdksh ? ]
vi-clones are really a personnal choice. I prefer vim but in emergency
situation, even the poorest vi is welcome. Without X or bindings extentions,
they are quite similar in size (although vim is a little bigger).
ee is not really required. I doubt that this package will be used by people
that don't know vi.
grep and awk are not required in this context.. nor is sed (vi can do
> <add only absolutely necessary utilities at this point>
see above. I don't know for mount and umount which I often needed in the
> Suggestions are welcome, but I just suggest that this list not get above
> between 6 and 10 utilities, as I must pull in the sources for them all,
> and manage their building together under the static linkage arrangement,
> and then bundle the executables into one Debian package.
with the list above, you need 4 (or 5) source packages :
- a shell
- a vi
- util-linux ([u]mount)
Fabien Tassin -+- email@example.com