systemd macros

Elan Ruusamäe glen at
Tue Sep 6 13:03:26 CEST 2016

(cc: devel-en list)

On 06.09.2016 13:11, gotar wrote:
> On Mon, Sep 05, 2016 at 23:59:25 +0300, Elan Ruusamäe wrote:
>> plz recheck your macros
>> this looks suspicious:
>>     foo || >/dev/null
> And it was wrong. There might be some other bogus code paths I didn't
> reached...
> I don't like our approach with hardcoding these macros as scripts in rpm
> packages, I'd be better (to update, test and maintain) to have them sit
> directly in filesystem, externally to rpm package.
yeap. i had this problem in 2005 already (%useradd, %service macros)

>   Currently we have to
> rebuild package to carry in some changes, e.g. my last change disabling
> fsync() on update-mime-database. If it happens that we want to reenable
> it, second run of rebuild is required (in such case I have had prepared
> sysconfig/rpm to handle fsync() switch variable).
we have some macros handled in filesystem, but owned by rpm.spec not 

$ rpm -ql rpm-base

thus, %banner and %userremove macros only

i  guess simplest would be to move them (with file history) to 
rpm-build-macros package, and build rpm-base from rpm-build-macro.spec 


More information about the pld-devel-en mailing list