Review Guidelines on -devel packages
by Michael Schwendt
https://fedoraproject.org/wiki/Packaging:ReviewGuidelines
| MUST: If a package contains library files with a suffix
| (e.g. libfoo.so.1.1), then library files that end in .so (without suffix)
| must go in a -devel package. [19]
[19] https://fedoraproject.org/wiki/Packaging/Guidelines#DevelPackages
Based on just the ReviewGuidelines, some packagers and reviewers
still get this wrong and create -devel packages for plugin .so libraries.
In particular because it is a MUST. The linked Packaging Guidelines page
on "Devel Packages" makes it a SHOULD and also mentions a rule of thumb,
but apparently this is still not clear enough.
How about this?
MUST: If a package contains library files with a numeric suffix
(e.g. libfoo.so.1 or libfoo.so.1.1), extra care must be taken to
distinguish between libraries needed at run-time and libraries
needed only when compiling/building software. Library files needed
only at build-time must be put into a -devel package. [19]
--
Fedora release 16 (Verne) - Linux 3.1.0-0.rc6.git0.3.fc16.x86_64
loadavg: 0.02 0.08 0.12
12 years
Ban autoloading of MPI environment
by Susi Lehtola
Hi,
the MPI guidelines currently state
"If the packager wishes to provide alternatives support, it MUST be
placed in a subpackage ..."
However, it has become clear that this statement is not clear enough
and warrants an additional specification. The guidelines were written
as to be fair to all people independent of the compiler and runtime
they are using.
However, some MPI runtimes have been misbehaving by autoloading their
environment with a file in /etc/profile.d placed in the runtime
package (BZ #647147). This has disunited the user interface and caused
many problems for package builders trying to compile a serial version
of an MPI-aware code (see for instance BZ #737043).
I am thus proposing that the MPI guidelines be clarified by the
additional statement
"MUST: If the maintainer wants to provide autoloading support for the
MPI environment, it must be placed in a separately installable
subpackage."
(see text in bold italics at
https://fedoraproject.org/wiki/PackagingDrafts/MPI )
--
Jussi Lehtola
Fedora Project Contributor
jussilehtola(a)fedoraproject.org
12 years
[Guidelines Change] Changes to the Packaging Guidelines
by Tom Callaway
Here are the latest changes to the Fedora Packaging Guidelines:
---
The section of the Packaging Guidelines regarding Compiler Flags has
been updated and improved, most notably, to document handling of PIE
enabled packages.
https://fedoraproject.org/wiki/Packaging:Guidelines#Compiler_flags
---
The prohibition against unnecessary explicit library requires has been
updated with an example of when explicit library requires are useful and
allowed. The example addresses packages that use features of a library
added after the library initially adopted its current SONAME.
https://fedoraproject.org/wiki/Packaging:Guidelines#Explicit_Requires
---
An additional md5 implementation was added to the list of bundling
exceptions:
https://fedoraproject.org/w/index.php?title=Packaging:No_Bundled_Librarie...
---
These guidelines (and changes) were approved by the Fedora Packaging
Committee (FPC).
Many thanks to Kevin Fenzi, Adam Jackson, 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,
~spot
12 years
Systemd upgrades and user-selected auto-start
by Stephen Gallagher
Our current scriptlets for systemd result in an unacceptable upgrade
case. Specifically, it reverts all services to their default
enabled/disabled status. We should allow packagers to include scripts
that keep the user-selected auto-start between upgrades.
For example, HTTPD does not start automatically when installed (because
its default configuration is not necessarily useful). However, once it's
been set up by a user and selected for autostart with ckconfig (for
example), we should not be disabling it on upgrade.
The reverse might also be true. In a hardened environment, a service
that is configured for auto-start by default might be disabled for
security reasons. Turning it back on by default during an upgrade could
then be viewed as a security vulnerability.
I think the guidelines need to be relaxed so that scriptlets like the
following could be added:
%triggerun -- sssd < %{version}-%{release}
if /sbin/chkconfig --level 3 sssd ; then
/bin/systemctl --no-reload enable sssd.service >/dev/null 2>&1
|| :
fi
if /sbin/chkconfig --level 5 sssd ; then
/bin/systemctl --no-reload enable sssd.service >/dev/null 2>&1
|| :
fi
/sbin/chkconfig --del sssd >/dev/null 2>&1 || :
In this case, we check to see if the sssd service was running in
runlevel three or five, and if so we enable it on upgrade. (Yes, I'm
aware that this is currently in violation of packaging standards, but
SSSD was converted prior to the standard being decided upon).
12 years
how to refer to files in the tarball
by Kalpa Welivitigoda
Hi,
I have a source tar of a package that I wish to package for fedora. To
install that there is a bash script should be done and that bash file
is inside the tar. How can I refer to that bash file (in the spec
file) in that tar to run it?
if the tar name is abc.tar.gz. the install.sh file in just inside abc.tar.gz.
Any help?
--
Best Regards,
Kalpa Pathum Welivitigoda
http://about.me/callkalpa
12 years
noarch vs missing deps
by Farkas Levente
hi,
the same problem happened against which i try to discuss earlier.
gstreamer-java is pure java package so it'd have to package as a noarch
package. which is true and can be working. but it has a subpackage
gstreamer-java-swt which is depend on eclipse-swt but still arch
independent. but when i try to build it in fedora's mock it goes most of
the time (as the noarch packages used to) to the ppc build server which
are try to satisfy it's buildreq. but it's depend on libswt3-gtk2 (which
is provided by eclipse-swt). but as eclipse can't be build on ppc (at
least i assume so) the ppc build server can't build it. even if the
resulting jar can be used/run even on windows!?
the worst part that i can't write ExcludeArch into a noarch rpm since
rpm do not allow it.
what is the solution? do i really have to make it none noarch?
or try richard's solution ie. try a few build and if it's choose x86
build server then i lucky!:-(
regards.
--
Levente "Si vis pacem para bellum!"
12 years
Removing files with RPM's build using python distutils
by Raoul Thill
Hi,
I am currently experimenting with packaging python projects using the
distutils library.
The packaging itself works fine, but I am having problems removing
outdated/removed files when incrementing the RPM release counter or the
version number. I thought that would be the RPM way :(
Could someone explain me how to remove files using an rpm package in
general, as I don't find anything related on the fedora packaging wiki
pages?
Example project structure:
project-root
-package1
--file1
-package2
--file1
--file2
Now packaging the project-root with both python packages works fine.
When removing the file2 from package2, the file is no longer in the new
resulting rpm with release=2 (0.1.1-2) or newer version (0.1.2-1), but
updating the package on the destination server using yum update, does
not remove the file. I suppose that I need to include a macro to remove
files on the destination server....
As my current projects are all hosted on GIT repos, would there be an
easier way to fulfill that task?
Many thanks for some help on that point.
Kind regards,
Raoul
12 years, 1 month
