On August 2, 2012 20:59:30 Paul Howarth wrote:
> On Thu, 02 Aug 2012 13:21:54 -0600
>
> Dmitry Makovey <dmi...@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.
---
_______________________________________________
epel-devel-list mailing list
epel-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/epel-devel-list
