[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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
something critical).

> > 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.

exactly.

> 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.

agree.
 
> 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.

/bin/sh     /sbin/sh
/bin/cp     /sbin/cp
/bin/rm     /sbin/rm
/bin/ln     /sbin/ln
/bin/ls     /sbin/ls
/bin/vi     /sbin/vi
/bin/chmod  /sbin/chmod
/bin/chown  /sbin/chown
/bin/mkdir  /sbin/mkdir

/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:
> 
> ash
> nvi/vim/elvis (someone else has to fight this one out)
> ee
> grep
> awk

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
the job).

> <add only absolutely necessary utilities at this point>

see above. I don't know for mount and umount which I often needed in the
past.
 
> 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 :
- fileutils
- sysvinit
- a shell
- a vi
- util-linux ([u]mount)

-- 
Fabien Tassin -+- fta@oleane.net


Reply to: