1 |
All, |
2 |
|
3 |
I got a clarification on irc that I would like to respond to, and I'll |
4 |
also respond to a couple of other things. |
5 |
|
6 |
On Mon, Jul 27, 2015 at 05:26:10PM -0500, William Hubbs wrote: |
7 |
> All, |
8 |
> |
9 |
> I have been looking over this bug for some time attempting to find a |
10 |
> good solution [1]. |
11 |
> |
12 |
> The original proposal is to add a "want" dependency which would work |
13 |
> like "need" but would not fail if the services wanted did not start [2]. |
14 |
> |
15 |
> I agree that the "want" dependency is a valid feature request. However, I |
16 |
> believe there is a better way to handle the issue in the original bug. |
17 |
> Basically, I want to follow the suggestion in this bug instead [3]. |
18 |
> |
19 |
> My concern about the original proposal is that it will make netmount try |
20 |
> to start all daemons that handle file systems, whether or not they are |
21 |
> actually necessary. |
22 |
|
23 |
It was pointed out to me that, if the want dependency was implemented, |
24 |
fstab could be parsed and want dependencies could be added for the |
25 |
specific network file systems needed. |
26 |
|
27 |
The trend seems to be moving away from relying on fstab contents, so I |
28 |
would rather not add more code that uses fstab unless it is necessary. |
29 |
|
30 |
Besides that, this approach still does not solve another issue I want |
31 |
to solve with separate mount tasks -- you can never know if a mount is |
32 |
successful or not because netmount and localmount must always return |
33 |
success. |
34 |
|
35 |
Concerns about the migration path and preserving legasy behaviour |
36 |
because people may not want to switch to the new system were brought up |
37 |
as well. |
38 |
|
39 |
I'll address the migration path first. |
40 |
|
41 |
I understand that some semblance of localmount and netmount will have to |
42 |
be around for a while until we fix the dependencies in our other |
43 |
services. |
44 |
|
45 |
I haven't figured out yet whether localmount and netmount should be |
46 |
rewritten as wrappers or left as they are for a couple of releases. |
47 |
|
48 |
I guess the easiest might be to leave them as they are for a couple of |
49 |
releases, but I'm not sure yet what the affect on the mount script will |
50 |
be if the mount script tries to mount something that has already been |
51 |
mounted by localmount or netmount. |
52 |
|
53 |
Either way, I'm thinking about adding deprecation messages to them to |
54 |
encourage service script authors to move away from them to depending on |
55 |
the specific file system mounts they need. |
56 |
|
57 |
Now I want to separately address the argument about preserving legasy |
58 |
behaviour just because it is there. |
59 |
|
60 |
Please understand. I'm not saying this to be sarcastic, it is an honest |
61 |
statement. |
62 |
|
63 |
I think providing a transition period to move to using new behaviour is |
64 |
perfectly reasonable, but I have a hard time understanding why old |
65 |
behaviour should be supported indefinitely, especially since users also |
66 |
have the choice to not upgrade packages if they need the old behaviour, |
67 |
and even more importantly, if the new behaviour is an improvement over |
68 |
the old behaviour. |
69 |
|
70 |
William |