On 12/17/2012 06:23 PM, William Hubbs wrote: > On Mon, Dec 17, 2012 at 01:31:59PM -0800, Greg KH wrote: >> On Mon, Dec 17, 2012 at 09:03:40PM +0100, J. Roeleveld wrote: >>> Olav Vitters <o...@vitters.nl> wrote: >>> >>>> On Mon, Dec 17, 2012 at 09:29:26AM -0500, Richard Yao wrote: >>>>> As I said in an earlier email, Lennart Poettering claims that it does >>>>> not work. We are discussing some of the things necessary to make it >>>> work. >>>> >>>> Just to repeat: >>>> In this thread it was claimed that a separate /usr is not supported by >>>> systemd/udev. >>>> >>>> A case which works with latest systemd on various distributions. I >>>> checked with upstream (not Lennart), and they confirmed it works. I can >>>> wait for Lennart to say the same, but really not needed. >>>> >>>> I assume this will again turn into a "but I meant something else". >>> >>> Olav. >>> >>> Lennart has stated that he considers a seperate /usr without init* broken. >> >> Yes, as do I, and so do a lot of other developers. >> >> But that is a system configuration issue, not a systemd issue, please >> don't confuse the two. >> >>> This has worked correctly in the past. >> >> Define "past" please. >> >> Note, it's still broken, I have yet to see any upstream fixes to resolve >> all of the issues that are involved here with "fixing" this up. >> >> Yes, as always, for some subset of users, you can be lucky and it will >> work for them, but those systems are getting rarer and rarer these days, >> as the rest of upstream (not systemd here) are moving on and not doing >> anything to change their behavior for this topic. >> >>> The direction udev development is going, according to Lennart, is to >>> make that impossible and he refuses to fix this regression. >> >> Again, this has NOTHING to do with udev or systemd, as has been pointed >> out numerous times. I understand your _wish_ that it would have >> something to do with it, but that will not change the facts, sorry. >> >>> I am really happy with this project and intend on testing it once >>> requests for this appear in the eudev mailing list. >> >> Good luck, the root problems still remain, and nothing that eudev ever >> does can resolve that, sorry. >> >> Can this topic finally be put to rest please? There is a whole web page >> devoted to this topic, why do people blindly ignore it? > > This is a very good question. > >> Again, a separate /usr without an initrd has NOTHING to do with systemd >> or udev, with the minor exception that Gentoo's packaging of those >> programs _might_ have an issue, but that is Gentoo's issue, NOT >> upstream's issue. >> >> If anyone involved with eudev, or is involved with the Gentoo Council >> thinks that the previous paragraph is incorrect, they are flat out >> wrong. > > This all started with the April 2012 council meeting when it was pushed > through that separate /usr without an initramfs is a supported > configuration, so yes, the previous council started this issue. > > Also, yes, eudev believes they will be able to fix it. > > I am another one who has been pointing out how this is wrong multiple > times but my statements about it are falling on deaf ears. > > William >
I have also explained how we can fix this multiple times and I can say that my explanations have been ignored. The eudev project's solution to this can be summarized in the few sentences that I said in a response to gregkh (after you wrote your email): >I reject >the notion that there be a single rules directory. That opens the door >to having a second directory on /usr that enforce the requirement that >rules that depend on /usr execute after /usr is mounted. The only argument that has been made against it involves libraries that cross the /usr boundary. I consider such situations to be avoidable. There has been no other argument made against this approach and I am quite confident that it is sound. Furthermore, it satisfies the request of various users to support a separate /usr mount without an initramfs. Satisfying that seems to me to be a worthwhile goal and it is one that I and others believe that we can do.
signature.asc
Description: OpenPGP digital signature
