Lennart Poettering (mzerqung(a)0pointer.de) said:
Hmm, so this is about files that are deleted but still mapped by
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?
I am not really convinced that reexecing is the right answer for
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
> 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
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'
something that could be stated correctly in mere LSB deps.
> OK, so now you've stated 5 times in this mail some
> 'that's not my package, it shouldn't be my problem, I don't want to
> 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
> 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
> 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.)