RPM variation
by Vadym Chepkov
Hi,
A typical rpm spec file has just one %build section and subpackages contain sub-set of the build tree. I want to create 3 different rpms with different names which follow "subpackage" schema, but, they will contain the full set of build files. I will explain why I need this.
IBM MQ Series provides very strange API. The function MQCONN, for example, will behave differently if you link your application either with -lmqm or with -lmqic (you have to choose one). The fist one is so called "server" version, second is "client" version and it depends on what MQ Series you use (client or server edition). In order to accommodate to this requirement, make files for my application have this logic:
ifndef WITHOUTMQ
MQDEFS = -DMQSERIES
ifdef WITHMQCLIENT
MQLIBS = -lmqic
else
MQLIBS = -lmqm
endif
endif
So I can create complete set of binaries for each case: no MQ at all, server or client installation. I want to pack results in 3 different rpms: app.rpm, app-MQServer.rpm and app-MQClient.rpm. rpm -ql for each package will list the same file names. How can I accomplish this in one spec file?
Thank you.
Sincerely yours,
Vadym Chepkov
15 years
Output from %post scriptlets
by Todd Zullinger
Are there guidelines on output from %post scriptlets? Specifically,
if a scriptlet calls service whatever condrestart, is it required to
send output to /dev/null? Most packages seem to do so, and the
scriptlet snippets for init scripts suggest this. But some packages
don't and the "stopping ... [OK]; starting ... [OK]' output is then
displayed when updating.
(I'm not suggesting that there should be a guideline on this, just
checking if there is one that I've overlooked. :)
--
Todd OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Liberty is always dangerous, but it is the safest thing we have.
-- Harry Emerson Fosdick
15 years, 1 month
Typo in GConf ScriptletSnippet
by Todd Zullinger
I think there's a typo at:
https://fedoraproject.org/wiki/Packaging/ScriptletSnippets#GConf
This chunk:
%post
export GCONF_CONFIG_SOURCE=<code>gconftool-2 --get-default-source</code>
gconftool-2 --makefile-install-rule \
%{_sysconfdir}/gconf/schemas/[NAME] .schemas > /dev/null ||| :
has an extra | at the end. It should end with '|| :' AFAIK.
--
Todd OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Ocean: A body of water occupying about two-thirds of a world made for
man -- who has no gills.
-- Ambrose Bierce
15 years, 1 month
Checking distro release from spec file
by Ray Van Dolson
I'm trying to write a "distro agnostic" spec file that will apply two
patches:
- Patch 1 if and only if we're building for EL5 or EL4
- Patch 2 if and only if we're building for EL4
I know I can check for EL with the presence of the %{fedora} macro, but
is there a "right" way to check the EL version short of calling rpm -q
redhat-release? I don't see a macro defined for this in /etc/rpm.
I guess I could operate on the dist tag...
Ray
15 years, 1 month
Meeting time
by Jason L Tibbitts III
So, what time is the next FPC meeting (tomorrow)? Are we moving for American
DST (which moves the time in Europe by an hour for, I believe, this one
meeting), moving for European summer time, or not moving at all?
http://fedoraproject.org/wiki/Packaging/Committee just says that we
use 17:00UTC and includes no rules about DST or summer time.
Personally, I have no preference and no conflicts either way.
- J<
15 years, 1 month
bad file in look-aside repository
by John Dennis
I need to correct a problem and I'm not sure the best way to handle it.
Unbeknownst to me upstream released a bad tar file. I uploaded it to the
look-aside repository via "make new-sources FILES=XXX". Upstream has
replaced the tar file with a new one and in the process removed a higher
version tar file I also uploaded (Arghh...)
I need to do the following two things, replace one file with another,
remove one file (because this file will at some point, e.g. next
version, will need to be in the repository, but just not now). FWIW no
build has been performed yet, thus by replacing and/or removing these
file it cannot lead to a non-repeatable build.
It seems as though "make new-sources" allows one to replace a file. Is
this true? If so I'm a bit surprised because it could permit malicious
behaviour and lead to non-repeatable builds.
Is there a mechanism to remove a file uploaded by mistake?
How can I avoid this problem in the future? I normally do a "make local"
when a new release comes from upstream and iterate locally until the
spec file and patch set is correct before doing a cvs commit, make tag,
make build. In the past this has always seemed safe and assured I didn't
get anything into our master until it was ready. However, "make local"
requires the tar file already be in the look-aside repository and you
may not know the tar file is hosed. I believe the same problem applies
to scratch builds. So, is there a way to test new builds locally without
having to have uploaded the sources first? (I know I can manually craft
an rpmbuild command line to emulate what "make local" would do, but it
would be better if one could ask the tools to do the equivalent of "make
local" without involving the look-aside.
--
John Dennis <jdennis(a)redhat.com>
Looking to carve out IT costs?
www.redhat.com/carveoutcosts/
15 years, 1 month
