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

Re: RES: /usr/lib vs /usr/libexec



> > That's a huge administrative hassle.  Not only do you have to figure
> > out what programs and libraries /bin/mount depends on so you can make
> > sure they're on your real root partition, but the packaging system
> > doesn't - and shouldn't - do anything to help you keep the two copies
> > of /bin in sync.

[Thomas Bushnell BSG]
> Um, that "figuring out" is *exactly* the figuring out that you are
> *already* doing in maintaining a separate /usr.

No.  Debian is figuring it out.  My whole point is that you've shifted
the job of doing so to the site admin.  If you are expecting dpkg to
take on the responsibility for peeking under people's mounted /bin
directories and installing/upgrading things on the root partition that
need to be on the root partition - then you're being absurd.

> > You would put up with all *that* for a 6-megabyte savings on your
> > root filesystem?
> 
> My /usr is rather more than 6 MB.

Well, my apologies, I was confusing your proposal slightly.  My
existing /bin is just over 6 MB, so overlaying *that* with only
/bin/mount and its helpers would save me that much.  I guess you're
talking about moving all of /usr into the root hierarchy, like the hurd
does upstream.

> > I should mention that I'm still waiting for your benchmark results
> > on how a drastic reduction in /usr/lib size speeds up the runtime
> > linker.  On *any* filesystem, O(n)-lookups or not.
> 
> Your demand to run a benchmark does not translate to an obligation on
> my part to run it.

Suit yourself.  I know you're educated enough to understand the
principle of burden-of-proof, and why this falls to the ones proposing
change.  If you base arguments for change on a speedup which ought to
be easily measurable, refusing to measure it degrades your position
considerably, and makes you look silly.  But that's not my bailiwick.

Attachment: signature.asc
Description: Digital signature


Reply to: