RPM macros question

Dmitry Makovey dmitry at athabascau.ca
Thu Aug 2 21:32:11 UTC 2012


On August 2, 2012 20:59:30 Paul Howarth wrote:
> On Thu, 02 Aug 2012 13:21:54 -0600
> 
> Dmitry Makovey <dmitry at athabascau.ca> wrote:
> > On August 2, 2012 20:12:10 Paul Howarth wrote:
> > > I don't think there's a standard for this, but an approach I've used
> > > with success is to test for the existence of the /run/lock
> > > directory:
> > > 
> > > # If directory /run/lock exists, do a systemd-based build;
> > > otherwise,a sysvinit-based build
> > > %global use_systemd %([ -d /run/lock ] && echo 1 || echo 0)
> > 
> > That's a good idea, thanks Paul.
> > 
> > Being paranoid I'm thinking of adding a step:
> > 
> > %global use_systemd %([ -d /run/lock ] && rpm --quiet -qf /run/lock
> > && echo 1 || echo 0)
> > 
> > that should make sure /run/lock is not there because it happened that
> > sysadmin just decided create it manually and doesn't happen to run
> > any systemd... Does that make sense?
> 
> Well it's fine in principle but unfortunately accessing the rpm
> database like that from within a package build is a bad idea because
> the build system may be using a chroot populated by a different version
> of rpm than the one the target system uses, which could make the rpm
> database unreadable at package build time, for instance if the builder
> and target systems use different versions of Berkeley DB.
> 
> The mock approach used in Fedora/EPEL is affected by this.

ouch. good to know, thanks!

> 
> Paul.
-- 
Dmitry Makovey
Web Systems Administrator
Athabasca University
(780) 675-6245
---
Confidence is what you have before you understand the problem
    Woody Allen

When in trouble when in doubt run in circles scream and shout 
     http://www.wordwizard.com/phpbb3/viewtopic.php?f=16&t=19330


-- 
    This communication is intended for the use of the recipient to whom it
    is addressed, and may contain confidential, personal, and or privileged
    information. Please contact us immediately if you are not the intended
    recipient of this communication, and do not copy, distribute, or take
    action relying on it. Any communications received in error, or
    subsequent reply, should be deleted or destroyed.
---




More information about the epel-devel-list mailing list