[Guidelines Change] Changes to the Packaging Guidelines
by Tom Callaway
Here is the latest set of changes to the Fedora Packaging Guidelines:
---
A bundling exception for boost within Passenger was granted, due to the
intrusive nature of the forked changes, the efforts of the maintainer to
merge as many of them as possible into the upstream boost source tree,
and the visible efforts of the upstream to keep the bundled copy of
boost in sync with the current boost releases.
The package must also include a Requires: bundled(boost) = $VERSION
where $VERSION is the boost version being bundled.
https://fedoraproject.org/wiki/Packaging:No_Bundled_Libraries#Packages_gr...
---
Packages which have SysV initscripts that contain 'non-standard service
commands' (commands besides start, stop, reload, restart, or
try-restart) must convert those commands into standalone helper scripts.
Systemd does not support non-standard unit commands.
https://fedoraproject.org/wiki/Packaging:Systemd#Unit_Files
---
A section was added to the systemd Packaging Guidelines page with a link
to the Tmpfiles.d Packaging Guidelines page, since systemd uses Tmpfiles.d.
https://fedoraproject.org/wiki/Packaging:Systemd#Tmpfiles.d
---
The Ruby Packaging Guidelines were almost completely rewritten. If you
maintain ruby packages in Fedora, we advise that you review the new
guidelines.
https://fedoraproject.org/wiki/Packaging:Ruby
---
An informational note about Software Collection macros in Fedora
Packages was added:
https://fedoraproject.org/wiki/Packaging:Guidelines#Software_Collection_M...
---
The guidelines relating to PIE and Hardened Packages were updated. Now,
if your package meets the following critera you MUST enable the PIE
compiler flags:
* Your package is long running. This means it's likely to be started and
keep running until the machine is rebooted, not start on demand and quit
on idle.
* Your package has suid binaries, or binaries with capabilities.
* Your package runs as root.
https://fedoraproject.org/wiki/Packaging:Guidelines#PIE
---
Rules involving appropriate scripting within Fedora Package spec files
were added to the Guidelines:
https://fedoraproject.org/wiki/Packaging:Guidelines#Scripting_inside_of_s...
---
The section in the systemd guidelines covering EnvironmentFiles and
support for /etc/sysconfig files was revised for clarification.
https://fedoraproject.org/wiki/Packaging:Systemd#EnvironmentFiles_and_sup...
---
The Ada Packaging Guidelines were updated for new rules on packaging
source files and updated macros.
https://fedoraproject.org/wiki/Packaging:Ada
---
The section of the Packaging Guidelines describing the "bootstrapping"
binary exception was amended for clarification:
https://fedoraproject.org/wiki/Packaging:Guidelines#Exceptions
---
The section of the Packaging Guidelines describing Duplication of system
libraries was amended to clarify the exceptions for Javascript and
parallel stacks.
https://fedoraproject.org/wiki/Packaging:Guidelines#Duplication_of_system...
---
These guidelines (and changes) were approved by the Fedora Packaging
Committee (FPC).
Many thanks to Kevin Fenzi, Bohuslav Kabrda, Brett Lentz, Marcela
Mašláňová, Bill Nottingham, Vít Ondruch, Mamoru Tasaka, and all of the
members of the FPC, for assisting in drafting, refining, and passing
these guidelines.
As a reminder: The Fedora Packaging Guidelines are living documents! If
you find something missing, incorrect, or in need of revision, you can
suggest a draft change. The procedure for this is documented here:
https://fedoraproject.org/wiki/Packaging/Committee#GuidelineChangeProcedure
Thanks,
~tom
12 years, 1 month
Basic Questions
by Kamal Ahmed
Hi List,
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
Thanks,
-Kamal.
12 years, 1 month
Filtering requires
by Brendan Jones
Hi all
I have a library (suil [1]) currently under review [2] 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
stage).
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?
thanks,
Brendan
[1] http://drobilla.net/software/suil/
[2] https://bugzilla.redhat.com/show_bug.cgi?id=783825
12 years, 1 month
EPEL packaging question - mozilla-adblockplus
by Russell Golden
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
images, javascript, and some XUL files. Definitely no Java, despite
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.
Russell Golden
Fedora Project Contributor
niveusluna(a)niveusluna.org
(972) 836-7128
--
"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."
12 years, 2 months
Ruby guidelines draft - further discussion
by Bohuslav Kabrda
Hi,
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 [1].
[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.
Pros:
-- 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.
Cons:
-- 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 :)
--
Regards,
Bohuslav "Slavek" Kabrda.
[1] https://fedoraproject.org/wiki/User:Toshio/RubyPackagingDraft#Some_notes
12 years, 2 months
