Re: Providing a static e2fsck ?
On Fri, 27 Mar 1998 18:36:25 EST "Adam P. Harris" (firstname.lastname@example.org
> [You (Philippe Troin)]
> >On Thu, 26 Mar 1998 00:01:22 EST "Adam P. Harris" (email@example.com
> >m) wrote:
> >> I for one am a proponent of having e2fsck, mknod, and ln be statically
> >> linking, or at least available in an alternatives package static.
> >And bash (to start mknod and ln), and init (to get to the point e2fsck
> >gets fired up), and a bunch of other utilities to have the boot scripts
> >run... and... and...
> No no no, not a full system, just a few things for single-user mode.
You'd need a shell anyways :-)
> >I thought the consensus was that statically linked executables was a
> >no-no because you need a bunch of basic programs statically linked.
> >And also to have all these packages recompiled whenever a libc security
> >patch is updated.
> >If my shared libraries and/or ld.so were screwed up, I would only
> >trust a boot disk to fix the damage anyways...
> mknod and ln have saved my buttg a few times. Once I had to use a
> statically linked xemacs (no joke) to fix a system hosed by an ld.so
> However, I agree, we've talked about this, and most people agree staticly
> linked binaries should not be shipped baseline, that's what the rescue
> disk is for, yadda, yadda. I agree with this.
> On the other hand, say I was in a fit or paranoia, couldn't I create a
> package which has static versions of essential programs that I saw fit,
> and couldn't I package it up and either use diversions on these binaries,
> or perhaps give them names like ln.static ? Would that be a *bad* thing?
> (Not that I have actual plans to do this at this time.)
Oh yeah, I have no problem with that as long as the regular packages are
You might want not to divert these because of the security problems
I've written about and maybe have them shipped as rwx------.
To UNSUBSCRIBE, email to firstname.lastname@example.org
with a subject of "unsubscribe". Trouble? Contact email@example.com