(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
_______________________________________________
pld-devel-en mailing list
[email protected]
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
