Lennart Poettering (mzerqung@xxxxxxxxxxx) said: > Hmm, so this is about files that are deleted but still mapped by init, > and which can only be deleted when init stops referencing them, but that > is required to remount the fs r/o? Did I get this right? Correct. > I am not really convinced that reexecing is the right answer for this > problem. But well, since this already works anyway I guess this doesn't > really matter too much. It's the only answer I know of which doesn't require kernel changes. > > > > PACKAGING > > > > - Guidelines for packaging systemd units shall be formalized. > > > > > > As pointed out elsewhere, I'd avoid this for F14. > > > > Then we should put "don't" in the guidelines, instead. We need to set clear > > expectations for package maintainers as to what they should be doing. (And > > certainly not switching the state of their packages mid-release.) > > Well, if we can agree on "don't, unless you contacted Lennart or [add > list here] and he said it's OK" then I am fine with this. That works for me. > Well, if we can agree on "after all sysv services that include no proper > ordering dependency information in the LSB headers", then I'd be fine > with this. If sysv services contain LSB headers, we should follow the > ordering it encodes, not come with implicit additional rules. SysV services don't have a dependency concept of 'this needs to run after me', AFAIK. So rc.local always implying 'I'm the last thing' isn't something that could be stated correctly in mere LSB deps. > > OK, so now you've stated 5 times in this mail some equivalent of > > 'that's not my package, it shouldn't be my problem, I don't want to be > > responsible for this.' > > > > I'm going to be blunt. I DON'T CARE. > > Yay, thanks that you don't care. You are aware that by putting > everything on a single man's shoulders and then telling him "you don't > care" you make him feel really welcome and make him wonder why he > even bothers with this shit? I'm not putting it on the shoulders of one man. I'm putting it on the shoulders of *the project*. These are the issues that need to work; these are the bugs that need to be fixed. If the scenarios have problems, we'll assign bugs and go from there. But in *generating* the scenarios that need to work, I'm not concerned with whose plate it falls on - it falls on everyone's. > > Sure, I suppose individual maintainers want to push their code over the wall and > > then sit in their silo and claim 'that's not my problem' and 'someone else > > needs to fix that', well, that's their right to be lame. But we, as Fedora, > > as producers of a product that we ship to our users, don't have that luxury. > > But you enable them to block out change. For example, if somebody > refuses to merge a patch that adds a systemd equivalent for an upstart > config hook he has, he can sink the whole systemd in fedora project. I > am pretty sure some folks would be really happy to have that power... That's what provenpackager and FESCo is for. We've forced patches to be merged in the past. (Related to PA, if I remember right.) Bill -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
