Re: from / to /usr/: a summary
Sorry for picking up this old thread, but...
On Mon, Jan 02, 2012 at 01:38:56AM +0100, Marco d'Itri wrote:
> On Dec 31, Russ Allbery <rra@debian.org> wrote:
> > Note that Steve's point, namely that he (if I'm reading him right) thinks
> > that the upstream changes are being overstated and that upstream's
> > direction isn't actually going to cause problems for us, is an entirely
> > separate one and not something I'm addressing in the above. And is
> > certainly something to explore before we start arguing over who's going to
> > fork something that may not be an issue at all.
> Unsurprisingly, this is not a black or white issue: there are many
> different issues in different parts of the stack and with different
> levels of complexity.
> In some cases I have been able to keep old code around (e.g. to support
> older kernels than upstream did), but in others it is intrinsecally
> impossible (e.g. when udev needs to IMPORT{} data from something which
> lives in /usr).
While I agree that forking upstream is not necessarily the right thing
to do, allow me to ask some things just so I understand things
better...
Do I understand you correctly that an empty configuration file in /etc
will override its 'full' equivalent in /usr? I.e., just an empty file
full of comments saying "this is what you can do with this file" will
break some things?
If so, are there some things in udev which intrinsically depend on that
behaviour? Or could you give me a rough gut-feeling estimation of the
amount of work that would be required to change it so it would work in
that way?
I think it's unfortunate that defaults are living outside of etc, but at
least if the files there can be made to exist in such a way that a
sysadmin knows where to look if he wants to change the defaults, then
the pain wouldn't be so bad.
--
The volume of a pizza of thickness a and radius z can be described by
the following formula:
pi zz a
Reply to: