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

Re: itp: static bins / resolving static debian issues



On Wed, Aug 18, 1999 at 07:54:11PM -0400, Raul Miller wrote:
> On Wed, Aug 18, 1999 at 06:11:27PM -0400, Justin Wells wrote:
> > >    -- we figure out what additional tools are required in order to 
> > >       get a root shell and repair a system, whatever sash does not
> > >       already supply, and add that to some /sbin directory.
> 
> > yep. 'ar' is the most obvious one. fdisk or sfdisk, e2fsck and mke2fs as
> > well. 'mount' is in sash but it might be worthwhile having a static bin
> > too.
> 
> ar I can see adding.
> 
> fdisk and e2fsck are outside the scope of what sash is supposed to
> deal with.  And you really wouldn't want to have to trust a sash
> reimplementation of e2fsck.

you're right on both counts. this functionality doesn't need to be in
sash, and i wouldn't want to trust an fsck built into sash.

the above were a list of additional tools to be compiled as static
binaries, to drop into a /sbin/static directory. i.e. in addition to
sash, not as extra functions to hack into sash.


> > and maybe a text editor (elvis-tiny, nvi, or vim-tty...and/or ae,
> > joe, or ee). 'ed' is in sash but it's not exactly pleasant to use.
>
> sash is not supposed to be pleasant to use.

agreed. 

however, if someone wants to make a package with a static binary of vi
or any other editor (or any other useful system recovery tool for that
matter), i see no reason to stop them.

> > (i'm disturbed even by the fact that the postinst for sash asks if
> > it should change root's shell to sash!)
>
> For the record, I'm disturbed by this as well, but I'm still (after a
> year) not sure what I'm going to do about it.

creating a sashroot or rootsash or whatever account as discussed in
another part of this thread is probably the best thing to do.

craig

--
craig sanders


Reply to: