[systemd-devel] RFC: creating a set of systemd RPM macros across distributions ?

[Kay Sievers]

On Wed, Jul 6, 2011 at 14:08, Frederic Crozat <fcrozat at suse.com> wrote:
> Le mercredi 06 juillet 2011 à 13:51 +0200, Kay Sievers a écrit :
>> On Wed, Jul 6, 2011 at 11:15, Frederic Crozat <fcrozat at suse.com> wrote:
>> > Le mardi 05 juillet 2011 à 23:39 +0200, Lennart Poettering a écrit :
>>
>> >> The simple fact is that we need a dependency on systemd anyway in the
>> >> RPMS to get the ownership for the units directory right. Now, if we have
>> >> "Requires: systemd" in the header, why do we also need "Requires(post):
>> >> systemd"? What does this buy us?
>> >
>> > Requires(post/preun/postun) on the package containing systemctl is
>> > needed as soon as systemctl is called in %post/preun/postun. A simple
>> > Requires is not enough, because you might end up installing systemd and
>> > the package requiring it in the same rpm transaction, but in the
>> > incorrect order.
>>
>> That's just not true. The 'Requires: systemd', which we always need
>> anyway, will ensure the proper install ordering just fine during a
>> transaction. Otherwise tons of similar things in that context would
>> just not work like they work today.
>>
>> Scriptlet dependencies are needed if cyclic loops need to be broken,
>> means systemd.rpm requires itself some other package which itself has
>> 'Requires: systemd'. Then the explicit scriptlet dependency binds
>> stronger than the normal Requires:, and ensures loop breaking at that
>> point in the circle.
>>
>> Or scriptlet dependencies are useful if the required package should be
>> able to get un-installed later, which isn't the case for systemd.
>
> This could be uninstalled, at least for now on non-F16 distribution ;)

No, you can't unless you fake all the directory ownerships, which
nobody should do. And if they do, upstream systemd should not care.
Scriptlet deps are not needed here, for people who play these games, a
simple '|| :' will make the failing command at un-install time a
non-issue.

>> I'm not saying we it might not be useful for corner cases, and if we
>> decide so, we might end up doing something like this, but it's surely
>> not *needed* at all for the common case, and if we need the reverse
>> for some special packages it might even get in our way.
>
> Having to handle this kind of corner cases (and I'm not as convinced as
> you it is a rare corner case) is a bad idea, specially since we can make
> sure the problem won't appear at all by using Requires(post...). I'm
> still strongly in favor of Require(post..), based on my experience in
> various RPM distributions..

Yeah, I'm just saying that we need to be careful with explicit
dependencies. It's like adding 'PreReq: systemd' to _every_ package
that installs a systemd service. I wouldn't be surprised if we can
have setups where we want the opposite dependency.

As said, we might want it and end up adding something like that for
specific reasons we discover. But we need to be careful here and needs
to be properly documented, and not explained as: 'This is needed.',
because it isn't for the common case.

Needlessly encoding harder requirements might get into our way, the
same way it might cause problems if we don't.

Kay