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

Re: deprecating /usr as a standalone filesystem?

Stefano Zacchiroli wrote:
On Wed, May 06, 2009 at 03:06:34PM +0200, Giacomo A. Catenazzi wrote:
But system administration is per definition ad hoc solution.
This is our power. Why we give sources? Also to allow us
to tweak debian.

This is a utterly poor argument.
I can easily twist it against you by saying "why we give binaries"?
We can just offer sources, system administrators will be able to
compile them.

I said *also*. 10 years ago this was a real argument:
"use Linux because you can adapt to your local needs".
I never installed a Debian system, which is 100% Debian.
It always have some of my personality.

For this case I mean: I don't think we should support
directly, but we should allow our sysadmin to tweak

Was this a topic of last meeting of the Italian cabal?

Is there anything useful in raising the "Italian cabal" here? The fact
I'm Italian has nothing to do with my arguments, pretty much as your
nationality has nothing to do with yours.
Or else add smileys if it was meant to be a joke.

sorry! Yes, it was meant as a joke.

But you are still selling us vapor!
We still don't understand the problem!

Anyhow, *you* don't understand the problem and you are probably the
only one thinking I'm selling vapor. From other people's replies I
conclude that the problem is quite clear and my vapor was so concrete
that others hinted at technical solutions.  But let me spell the
problem out for you, as you are raising the tone of the discussion
with exclamation marks (which was not my intention).

The problem is that our package manager (dpkg) assumes it is in charge
of files which reside on different top-level FHS directories: /usr,
/var, /boot, /bin, /sbin, /lib, /lib64, ...

In a scenario where /usr is remotely exported for NFS mounting, if you
use dpkg on the exporting machine, client machines will get out of
sync. Some files need to be copied over statically and, more
interestingly, maintainer scripts will need to be re-run on client
machines to deliver their side effects to all machines. Also the
status of the dpkg database need to be synced with clients.

No. So I think also you did not understand the real problem.
The /usr in NFS is one interpretation, but I really think it was not
the original problem. Such ad hoc methods was never supported.

[BTW we saw in the thread that we could share also / on multiple systems!]

I think the problem is having /usr in an other partition
(a larger set of configuration, and in this case, we supported it), thus
having problem at boot, on what the init script could expect
(program and libraries).

Sorry for my tone, but we are disturbed on the fact that
a proposal was done without giving reasons.


Reply to: