On Wed, Jul 6, 2011 at 14:08, Frederic Crozat <[email protected]> wrote: > Le mercredi 06 juillet 2011 à 13:51 +0200, Kay Sievers a écrit : >> On Wed, Jul 6, 2011 at 11:15, Frederic Crozat <[email protected]> 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 _______________________________________________ systemd-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/systemd-devel
