systemd macros

Elan Ruusamäe glen at pld-linux.org
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-build-macros.spec

$ rpm -ql rpm-base
/etc/rpm
/etc/sysconfig/rpm
/usr/bin/banner.sh
/usr/lib/rpm
/usr/lib/rpm/user_group.sh
/var/lib/banner

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 
package



-- 
glen



More information about the pld-devel-en mailing list