On Sun, Sep 06, 2009 at 12:56:03AM +0200, Marco d'Itri wrote: > > > They are currently providing most of the manpower for developing udev > > > and the related infrastructure so this is pretty much the practical > > > effect, yes. > > So what, you think this means we don't have any right to object when they > > design things wrong? > No, I mean that after objecting and failing to have my objections > accepted, I have no other means of steering development in a different > direction. If you're unable to persuade upstream to change their implementation, and you're unwilling to diverge from upstream to ensure the package complies with Debian policy, your other option is to orphan the package and let someone maintain it who is willing to ensure it complies with Debian Policy. I don't mean to imply that this last is what you should do; I'm merely pointing out the set of options at your disposal. And pointing out that shipping a package that violates Debian Policy in such a blatant manner isn't one of those options. > I objected, multiple times, alone, and then started a discussion here. > What did *you* do other than accusing me? I appreciate that you took the time to bring this issue to the project's attention. What I don't appreciate is your statement that you don't intend to do anything about it (there's a policy violation, one of your packages is involved; it's your responsibility as a maintainer to help find a solution), or your claims that we shouldn't care about FHS compliance if Red Hat and SuSE don't. As for me, what I am doing is making sure I have all the facts so that I can take this issue upstream as you suggested. > > Violating the FHS is incompetent by definition and any resulting design is > > unreliable. > Maybe you were not involved with FSSTND and FHS development at the time, > but in multiple occasions it was modified to reflect what distributions > actually wanted to implement of previous versions of the specification, > like when /usr/libexec and /var/state were added and then removed again > (it was about 1997). > I was following FHS development at the time and I remember it. I am familiar with the history of the FHS. It's normal that in the process of drafting a standard, people will take into account the prevailing real-world practices, to ensure that the standard will be useful. Once something *is a standard*, you don't arbitrarily change what you're doing and claim that it still complies with the standard because "the standard follows what Red Hat does". The FHS as part of Debian Policy is a promise to our users that they can rely on the system working a certain way. It's not ok for *any* upstream to force us to break that promise, no matter how important they think they are. > > That bug was reopened as a result of a conversation I had with Martin and > > Scott in response to this precise thread. I was hoping Scott would be able > > to shed some light on the motivation for this goofy design, but he was just > > as much in the dark regarding the reason this was added and wasn't aware of > > the FHS problem that had been introduced. > But he was aware of other /usr-related issues in udev, and his answer > was that Ubuntu does not support standalone /usr filesystems. Do you have a pointer to where he said this, or was this another unlogged IRC discussion? The last time you made this claim, I asked Scott about it and he denied that this was his position. Given that there has quite specifically been work put into making /usr-on-a-separate-filesystem work in Ubuntu in the last release cycle (work that unfortunately has been undone to some degree by devicekit without anyone noticing until now), I would like to make sure we do have a shared understanding of how this is supposed to work, but it's hard to do this when all I have is hearsay. > > Do you have a reference to a thread where someone upstream has acknowledged > > the existence of this FHS bug and proceeded to implement this anyway? > There was at least > http://article.gmane.org/gmane.linux.hotplug.devel/14384 , but most > discussions happened on IRC where everybody else involved explained in > no uncertain terms that they do not want to support a standalone /usr > filesystem. Ok, thanks for the reference. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer http://www.debian.org/ slangasek@ubuntu.com vorlon@debian.org
Attachment:
signature.asc
Description: Digital signature