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 <r...@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 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120127094607.gd21...@grep.be