Right now, mounts and related tasks in OpenRC are performed in init.d files corresponding to particular tasks or groups, i.e. fsck, localmount, netmount, swap... This means that it is a kind of all-or-some policy. For a more stateful behavior, OpenRC would have to split this to controlling every single mount point via a separate init.d file, possibly a 'virtual' one. Of course, this involves either adding support of starting semi-virtual services (possibly derived, much like {net.foo, net.bar} -> net) or generating init.d files on-demand (in /run or similar storage location). In systemd, each mount point has its own separate fsck and mount units. OpenRC would probably benefit from such a structure as well, with mount unit depending on the respective fsck unit, and various mounts depending one on another to enforce correct mount order. As I see it, the advantages of such a solution would be: 1) ability to control individual mounts, 2) clear mapping of fsck errors to particular mounts, 3) ability to add or remove entries to fstab in runtime in a safer manner, 4) ability to delay non-important mounts to reduce HDD load. On the other hand, it would require OpenRC to become aware of /etc/fstab file format.
@qa: I was looking through outstanding OpenRC bugs a few days ago and came across this one. The new design has several strong points in its favor which I will point out below. However, Rick says it conflicts with a previous qa decision. Here are some things that are interesting about this design: - bug #215616: I don't really agree with the suggestion in this bug; I think it could be handled better if services could depend on individual file systems. - bug #219823: This is purely an ordering issue and would go away with the new design. Right now we are basically telling users there is nothing we can do, but the new design would take care of it because users would be able to set the order of mounts and unmounts themselves. - bug #375597: This bug won't go away with the new design. However, the situation will improve since we will be looking at individual file systems not unmounting instead of all network file systems not unmounting. - Bug #468600: This is a long standing incompatibility between OpenRC and busybox which would go away with the new design. This bug could be removed from tracker bug #529086 - bug #468604: Same as #468600. - Bug #537996: The new design would obsolete the localmount and netmount services, but NOT the want dependency in bug #406021. I've started working on this new design, and there is good discussion going on about it on the ml [1] [2]. I am escalating because I need to know whether the decision on bug #537996, which was that I would implement the want dependency then accept patches from Rick to the netmount script to implement scanning fstab and adding want dependencies based on the contents blocks me from improving things a different way; in particular, in a way that I feel has a strong case. @pinkbyte: You supported Rick's position, so since you are the qa lead, your input would be greatly appreciated. [1] https://archives.gentoo.org/gentoo-dev/message/de37debe616b1d94de5352baed152177 [2] https://archives.gentoo.org/gentoo-dev/message/1417517d16d44c0ad66a875b615b1509
there is no need to block openrc development. My goal in asking for "want" support is only to fix the failures in openrc as it cannot mount some filesystems without help right now. It would seem desirable to implement something as simple as "want" (which is really just like "need" accept always returns success) as a short term fix, however, the QA meeting suggesting that was months ago yet there has been no progress. As the upstream for an open source project (openrc), gentoo cannot order Williamh to do anything he doesn't want, a fact clearly demonstrated by the fact that he hasn't copy and pasted want into need and removed the (if I had to guess) || die from the code. William, The Gentoo Quality Assurance Team officially requested that you (the upstream developer) add "want" support to openrc to fix a known gentoo bug. This is, in my belief, the limit of Gentoo's power. It is up to you if you will choose to grant this request As the request to add want support was made on 2015-02-18, and it is now 2015-07-31, it would appear to me as though you have no desire to fulfill the official request for fixing a bug in gentoo. I see no action that Gentoo as a project can take to force an upstream project to bow to us.
I suppose it should be added as the last line, "Nor should we try".
Not sure if you really need QA anymore here. Rick doesn't want to block your work, other QA members are silent and I pretty much agree with him that you are the upstream and you decide how to proceed. Worst case, Gentoo forks OpenRC :). But seriously, if you can implement a better solution that will fix the underlying issue, nobody is going to complain. Well, except the few usual complainers who believe that any change is bad.
Dropping qa@. William still wants to work on this.
