All, I got a clarification on irc that I would like to respond to, and I'll also respond to a couple of other things.
On Mon, Jul 27, 2015 at 05:26:10PM -0500, William Hubbs wrote: > All, > > I have been looking over this bug for some time attempting to find a > good solution [1]. > > The original proposal is to add a "want" dependency which would work > like "need" but would not fail if the services wanted did not start [2]. > > I agree that the "want" dependency is a valid feature request. However, I > believe there is a better way to handle the issue in the original bug. > Basically, I want to follow the suggestion in this bug instead [3]. > > My concern about the original proposal is that it will make netmount try > to start all daemons that handle file systems, whether or not they are > actually necessary. It was pointed out to me that, if the want dependency was implemented, fstab could be parsed and want dependencies could be added for the specific network file systems needed. The trend seems to be moving away from relying on fstab contents, so I would rather not add more code that uses fstab unless it is necessary. Besides that, this approach still does not solve another issue I want to solve with separate mount tasks -- you can never know if a mount is successful or not because netmount and localmount must always return success. Concerns about the migration path and preserving legasy behaviour because people may not want to switch to the new system were brought up as well. I'll address the migration path first. I understand that some semblance of localmount and netmount will have to be around for a while until we fix the dependencies in our other services. I haven't figured out yet whether localmount and netmount should be rewritten as wrappers or left as they are for a couple of releases. I guess the easiest might be to leave them as they are for a couple of releases, but I'm not sure yet what the affect on the mount script will be if the mount script tries to mount something that has already been mounted by localmount or netmount. Either way, I'm thinking about adding deprecation messages to them to encourage service script authors to move away from them to depending on the specific file system mounts they need. Now I want to separately address the argument about preserving legasy behaviour just because it is there. Please understand. I'm not saying this to be sarcastic, it is an honest statement. I think providing a transition period to move to using new behaviour is perfectly reasonable, but I have a hard time understanding why old behaviour should be supported indefinitely, especially since users also have the choice to not upgrade packages if they need the old behaviour, and even more importantly, if the new behaviour is an improvement over the old behaviour. William
signature.asc
Description: Digital signature
