I just started working on RPM Packaging and had few questions.
1. Where can i find good "WORKING" Examples of packages.spec
2. Is mach, or mock, really the better version of rpmbiuld ?
OK, so you want to build a binary RPM package for deployment on your
servers. You have a .spec file or .src.rpm that you got from one of the many
repositories such as freshrpms.net or dag.wieers.com, or that you wrote yourself.
Why not just build it using rpmbuild?
There are several problems you may come across.
1. Given a spec file, rpmbuild won't download the source tarball and/or
patches. You have to fetch those yourself into the SOURCES directory.
2. rpmbuild will abort if any build-time dependencies are missing, forcing
you to stop what you're doing, and go and build and install those packages too.
3. When your package configures itself, it may auto-detect libraries which
are available on your build system, but which are not going to be available
on the target system. For example, if openldap-devel is present then
openldap may be linked into your binaries, but if the RPM doesn't declare
openldap as a dependency, then it will fail to run on the target system.
This is an insiduous problem, which I call "the curse of autoconf".
4. You can only build packages for the same type of system as your build
machine (e.g. CentOS 4 binaries on a CentOS 4 build system)
If you want an example of how bad the problem is, try building the package
perl-SOAP-Lite from its spec file. You will
quickly find yourself in dependency hell, with 16 other packages needing to
be installed or built, all in the correct order.
The solution: mach
3. Can i install "use sudo yum install <package name> , inside a SPEC file ?
4. How can do a CHROOT inside a SPEC File
5. How do i introduce versions, r=for RPMs, when there is NO version in the SCM ( we are using Mercurial )
6. Is there a working automation framework for rpmbuild ?
7. I tried using autospec , but it includes all the source files as well. I used it as:
tar tzf myapp-0.1.tar.gz | autospec -bd -c GPL -g Utilities/System -n myapp-0.1 -l '' > myapp.spec
I have a library (suil ) currently under review  which enables
audio software such as qtractor/ardour etc to instantiate LV2 audio
plugins. Whilst not part of the LV2 specification, it is being
maintained by the authors of LV2 and will obsolete slv2 which is what
hosts currently use.
An instantiated plugin may use a different UI toolkit than the host and
one of purposes of the suil library is to free the host application from
unnecessary explicit runtime toolkit dependencies (Qt/Gtk only at this
As it stands RPM automatic requires will pull in requires for both
toolkits, so that any Qt host using suil will pull in Gtk and vice
versa. Whilst on most systems these will be present anyway it may not
always be the case nor desirable (and it kind of defeats what upstream
have set out to achieve).
I can filter out the toolkit requires in suil which will solve the
problem, but it leaves the maintainer (me for now) in a position of
manually tracking changes in Qt/Gtk that may require a rebuild of suil.
Alternatively I could filter the requires on any hosts that use suil,
(only one at this stage but inevitably more), but that again this is
cumbersome as more and more hosts come onbooard.
The safest course is to leave the automatic requires alone, pull in both
toolkits for every host and deal with it differently when/if asked but
it doesn't sit *right* with me.
Any comments on the best way to handle this?
mozilla-adblockplus won't build in EL6. I suspect the version of
python-jinja2 is too old.
My question: The upstream XPI for mozilla-adblockplus includes a JAR
file. This JAR file contains _no_ libraries or binaries. It only has
the JAR extension.
It appears to me that there are three options.
Option 1: Unpack the upstream XPI and ship that.
Option 2: Figure out how to make this package build, if it can at all.
Option 3: Retire the package. AdBlock Plus 1.x will be disabled by
default in Firefox 10 without disabling addon compat checking, and I'm
not even sure it will work at all.
Fedora Project Contributor
"We are the Borg. Lower your shields and surrender your ships. We will
add your biological and technological distinctiveness to our own. Your
culture will adapt to service us. Resistance is futile."
as it was said on the fpc meeting, I'm writing to comment on the section "Some Notes" in Toshio's draft of new Ruby packaging guidelines .
[citing the lines from "Some Notes" one by one]
- "Need to move the rubygems library into the per-interpreter directories as it is a non-gem library."
As we have said with Mo Morsi, Rubygems library should stay out of Ruby directory structure.
-- Prooves to Rubygems and JRuby upstreams that Rubygems library can be unbundled from Ruby and it makes sense to work on merging the JRuby changes in Rubygems upstream to make one general Rubygems library (that should therefore be implementation-independent).
-- As noted by Toshio on the fpc meeting, our system-wide Rubygems are currently only used by MRI Ruby. But as I've said, we need to take steps gradually to convince the upstreams of feasibility of such changes and not to break anything. It is true, that JRuby currently ships with it's own modified (non-compatible) version of Rubygems, but we are working to merge their changes into Rubygems upstream. So yes, currently in F17, there is only the MRI Ruby using the system-wide Rubygems, but the support for JRuby is comming (perhaps F18?). If we are discussing this only from F17 point of view, we still may want to package Rubinius there (it is on our todo list, although not that high as JRuby) and Rubinius _would_ be able to use the system-wide Rubygems - that is another reason why Rubygems should stay where they are even in Fedora 17.
-- Toshio says that he doesn't like special-casing and Rubygems should ship inside each of the Ruby implementations, until we make all the changes to have system-wide Rubygems, that work with all Ruby implementations (I hope I am not misinterpreting you, if yes, then please correct me). I'd like to add, that it is very hard to convince Rubygems upstream to make any changes that we need and we must have something to show them it's worth the work to merge the JRuby changes in.
-- Any others?
- "Need to rebuild ruby and rubygems package to use the new location"
-- I think that depends on whether the Rubygems library is moved, so let's put it aside for the moment and discuss it afterwards.
- "Need to rebuild rubygem packages to use the new interpreter-neutral rubygem library location."
-- Same as above.
- "Should there be more information about jruby, etc in the introductory portion (naming and" [unfinished]
-- I think it would be good to postpone this until we have better integration with the other Ruby implementations. So far, no one has requested any JRuby specific packages or anything connected with JRuby, so I would leave that for a separate discussion/fpc ticket.
- "gem2rpm and rpmdev-newrpmspec can be updated with the new template"
-- Yes, we will do that once the guidelines are complete. I hope that the gem2rpm part of guidelines will then be added back.
Thanks for reading this through :)
Bohuslav "Slavek" Kabrda.