On Thu, 13.09.12 08:48, Simone Caronni (negativo17@xxxxxxxxx) wrote: > Hello, > > On 13 September 2012 08:06, Lennart Poettering <mzerqung@xxxxxxxxxxx> wrote: > > Since F16/F17 do not have presets we cannot just port those macros > > there. What is one macro in F18 would map to two macros in F16/F17. > > Can you please point me to the two macros? I only see a small difference. On F16/F17 in postinst you have to do "systemctl enable" to enable a service. To leave a service disabled you do not invoke systemctl at all. Whether a service is enabled or not after installation is encoded in the package itself and hence it is up to the package maintainer whether he includes the "systemctl enable" or not. To turn this into a postinst macro you'd have to introduce two macros: one with and one without the "systemctl enable". On F18 in postinst you have to do "systemctl preset" unconditionally. Whether a service is enabled or not after installation is no longer encoded in the package itself but in the preset policy of the distro/spin/admin. Since there's only one possible operation here we only have one macro for postinst: the one which invokes "systemctl preset". In other words: A) There's one postinst script that invokes "systemctl enable" B) There's another one that does not invoke systemctl, and leaves the service off C) There's a third one that invokes "systemctl preset" In F16/F17 A and B are used. Some packages use A, most packages use B. In F18 only C is used. All packages use C. In F18 we have a macro that implements C. We have no macro that implements A or B. Now, you are asking me to provide a macro with the same name and functionality in F16/F17 as the one we introduced for F18, right? But how could we do this? If on F18 the macro implements C, what would it implement on F16/F17? Would it implement A? If so, it would be useless for all packages whose service needs to stay off after installation. Would it implement B? If so, it would be useless for all packages whose service needs to be enabled after installation. Of course we could introduce new macros for both A and B, so that we'd have three macros, covering all three operations. But who'd be helped with that? We should introduce new stuff only for new distros, and maybe backport it. But this would be adding completely new stuff to old distros that makes no sense anymore on new distros, and hence we shouldn't do it. Hope this clarifies this a bit. Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
