1 |
On 12/17/2012 04:31 PM, Greg KH wrote: |
2 |
> On Mon, Dec 17, 2012 at 09:03:40PM +0100, J. Roeleveld wrote: |
3 |
>> Olav Vitters <olav@×××××××.nl> wrote: |
4 |
>> |
5 |
>>> On Mon, Dec 17, 2012 at 09:29:26AM -0500, Richard Yao wrote: |
6 |
>>>> As I said in an earlier email, Lennart Poettering claims that it does |
7 |
>>>> not work. We are discussing some of the things necessary to make it |
8 |
>>> work. |
9 |
>>> |
10 |
>>> Just to repeat: |
11 |
>>> In this thread it was claimed that a separate /usr is not supported by |
12 |
>>> systemd/udev. |
13 |
>>> |
14 |
>>> A case which works with latest systemd on various distributions. I |
15 |
>>> checked with upstream (not Lennart), and they confirmed it works. I can |
16 |
>>> wait for Lennart to say the same, but really not needed. |
17 |
>>> |
18 |
>>> I assume this will again turn into a "but I meant something else". |
19 |
>> |
20 |
>> Olav. |
21 |
>> |
22 |
>> Lennart has stated that he considers a seperate /usr without init* broken. |
23 |
> |
24 |
> Yes, as do I, and so do a lot of other developers. |
25 |
> |
26 |
> But that is a system configuration issue, not a systemd issue, please |
27 |
> don't confuse the two. |
28 |
|
29 |
You can add me to that list. The only difference is that I feel |
30 |
differently about what the proper solution is. In particular, I reject |
31 |
the notion that there be a single rules directory. That opens the door |
32 |
to having a second directory on /usr that enforce the requirement that |
33 |
rules that depend on /usr execute after /usr is mounted. |
34 |
|
35 |
>> This has worked correctly in the past. |
36 |
> |
37 |
> Define "past" please. |
38 |
> |
39 |
> Note, it's still broken, I have yet to see any upstream fixes to resolve |
40 |
> all of the issues that are involved here with "fixing" this up. |
41 |
> |
42 |
> Yes, as always, for some subset of users, you can be lucky and it will |
43 |
> work for them, but those systems are getting rarer and rarer these days, |
44 |
> as the rest of upstream (not systemd here) are moving on and not doing |
45 |
> anything to change their behavior for this topic. |
46 |
|
47 |
In practice, the majority of users have no issues in areas that matter |
48 |
to them. Those that do seem to be a small minority. |
49 |
|
50 |
>> The direction udev development is going, according to Lennart, is to |
51 |
>> make that impossible and he refuses to fix this regression. |
52 |
> |
53 |
> Again, this has NOTHING to do with udev or systemd, as has been pointed |
54 |
> out numerous times. I understand your _wish_ that it would have |
55 |
> something to do with it, but that will not change the facts, sorry. |
56 |
|
57 |
It can be said that the systemd developers are not very accommodating to |
58 |
people who want to pursue alternative solutions. |
59 |
|
60 |
>> I am really happy with this project and intend on testing it once |
61 |
>> requests for this appear in the eudev mailing list. |
62 |
> |
63 |
> Good luck, the root problems still remain, and nothing that eudev ever |
64 |
> does can resolve that, sorry. |
65 |
> |
66 |
> Can this topic finally be put to rest please? There is a whole web page |
67 |
> devoted to this topic, why do people blindly ignore it? |
68 |
> |
69 |
> Again, a separate /usr without an initrd has NOTHING to do with systemd |
70 |
> or udev, with the minor exception that Gentoo's packaging of those |
71 |
> programs _might_ have an issue, but that is Gentoo's issue, NOT |
72 |
> upstream's issue. |
73 |
> |
74 |
> If anyone involved with eudev, or is involved with the Gentoo Council |
75 |
> thinks that the previous paragraph is incorrect, they are flat out |
76 |
> wrong. |
77 |
> |
78 |
> greg k-h |
79 |
> |
80 |
|
81 |
The systemd developers do not appear to accept patches unless the |
82 |
patches have direct relevance to Fedora. Many people consider this to be |
83 |
an upstream issue in the context of that. They likely would not think |
84 |
such things had the systemd developers said that they would welcome |
85 |
patches to improve separate /usr support, despite the fact that it would |
86 |
never be used in any configuration that they care to support. The |
87 |
disdain that they have expressed toward such configurations provides |
88 |
validation for such beliefs. |