On Tue, 05.07.11 18:37, Frederic Crozat ([email protected]) wrote: > > > the point is to have a common macro which would allow packagers to > > > ensure they don't forget anything. The name of the package pulled by > > > this macro is not relevant. > > > > Yeah, and again, it's just 'Requires: systemd', and I think no need to > > play distro-package indirection/abstraction games here. > > No, it is : > Requires(post) > Requires(preun) > Requires(postun) > > and from experience, people tends to forgot one or another. Using a > macro helps for readability and consistency. > > But if you really don't want this macro, I guess it will be SUSE only..
Oh, we all want standardized systemd macros for RPM, there's not doubt on that. The question is just how exactly they should look like. And that means two things: first we have to agree how the macro should be called (and that implies figuring out policy of enabling and stuff, since we probably shouldn't suggest in the name of a macro that it does specific policy decisions if later on we decide to do policy completely differently -- for example with the preset stuff I just posted the RFC about), and secondly we have to agree how the default macro definitions should look like. Kay just wanted to point out that the Requires(post) might not be the right choice to place in the default macross. The simple thing is that if we add this to systemd (or RPM, but I prefer systemd) then this will be something gazillions of packages will rely on, or will even copy, so we really should get it right. And that includes that we need to question every single line of it, which in this case raised some eyebrows on the usefulness of Requires(post) and friends if Requires is already in the header anyway. 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? Lennart -- Lennart Poettering - Red Hat, Inc. _______________________________________________ systemd-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/systemd-devel
