packaging September 2006

packaging@lists.fedoraproject.org

36 participants
29 discussions

ReviewGuidelines: What are proper permissions?
by Till Maas 20 Sep '06

20 Sep '06

Hiyas, ReviewGuidelines say: MUST: Permissions on files must be set properly. Executables should be set with executable permissions, for example. I just noticed that there are some files with permissions 0444 on my fc5 system installed, for example manpages: -r--r--r-- 1 root root 24410 15. Feb 2006 cdrecord.1.gz -r--r--r-- 1 root root 1229 11. Feb 2006 dos2unix.1.gz -r--r--r-- 1 root root 1790 11. Feb 2006 hesinfo.1.gz Are 0444 proper permission bits for manpages / non-executable files? Regards, Till

3 2

changelog entries: release with disttag?
by Till Maas 19 Sep '06

19 Sep '06

Hiyas, what information about E-V-R should be in changelog entries? In http://fedoraproject.org/wiki/Packaging/Guidelines#head-b7d622f4bb245300199… the first example is: * Wed Jun 14 2003 Joe Packager <joe at gmail.com> - 0:1.0-0.fdr.2 This seems to contain %{?dist} (fdr) but the other examples do not. This is irritating. And as far as I understand the NamingGuidelines 0.fdr.2 is not a valid release tag nowadays. In http://lemenkov.newmail.ru/SPECS/sipsak.spec (sipsak has been submitted as a review request (206872)) %{?dist} is used in a changelog entry, is this allowed? Regards, Till

2 4

No pre-built applications rule
by Toshio Kuratomi 18 Sep '06

18 Sep '06

Hey guys, It's come to my attention that we don't have a "Packages must be built from source, no precompiled binaries" rule in the current guidelines. I think this is an oversight as the Binary Firmware section: http://www.fedoraproject.org/wiki/Packaging/Guidelines#BinaryFirmware implies this for the specific case of firmware. How about something like: "Packages must be built from source code. Including pre-built programs or libraries is strictly forbidden. A select few exceptions are made for binary firmware. Please see http://www.fedoraproject.org/wiki/Packaging/Guidelines#BinaryFirmware for details." And on ReviewGuidelines: "Must: The package must be built from source. No pre-built programs or libraries are acceptable." Thoughts, opinions welcome. -Toshio

9 16

Kernel Module Packaging
by Parag Nemade 15 Sep '06

15 Sep '06

Hi, I am planning to submit kernel module packages which are not in mainstream kernel yet. May i know what guidelines should i follow? Do Fedora Packaging people confirmed on any kernel module packaging guidelines? I saw already many packages waiting for review in FE and yet no progress for them. why so? I don't understand why Fedora people don't want kernel module package that do not satisfy "A publishable explanation from the author(s) why the module is not merged with the mainline kernel yet and when it's planed to get merged. You of course can ask the author to explain it directly in the bug report. " How then ubuntu/debian distribution got them included in their OS? I saw many peoples claiming on IRC channels that they got many kernel module packages from their distro only and enjoying their usage then why Fedora is having objection on those waiting FE review packages? BTW is kmdl approach accepted or not? If not then should we let new kernel modules submissions according to kmod approach? Regards, Parag.

5 9

Including a CHANGELOG in php-pear extension package.
by Remi Collet 13 Sep '06

13 Sep '06

Do you thinks it's a good idea ? I wrote a little script to extract the CHANGELOG from the package.xml provided by the upstream package. Only have to add to the spec : Source2: xml2changelog In %prep : %setup -q -c [ -f package2.xml ] || mv package.xml package2.xml + %{_bindir}/php -n %{SOURCE2} package2.xml >CHANGELOG mv package2.xml %{pear_name}-%{version}/%{pear_name}.xml and, of course %doc CHANGELOG Here is my script : <?php $prog=array_shift($_SERVER['argv']); if ($_SERVER['argc']<2) die ("usage : " . $prog . " path_to_package.xml\n"); $file=array_shift($_SERVER['argv']); ($xml=simplexml_load_file($file)) || die ($file . " not found !\n"); printf("* Version %s (%s) - %s\n\n%s\n\n", $xml->release->version, $xml->release->state, $xml->release->date, $xml->release->notes); foreach($xml->changelog->release as $rel) printf("* Version %s (%s) - %s\n\n%s\n\n", $rel->version, $rel->state, $rel->date, $rel->notes); ?>

1 0

pkgconfig dependency question
by Orion Poplawski 12 Sep '06

12 Sep '06

After skimming some of the thread about .pc files in -devel or not, it seems like .pc files should be generating automatic dependencies. Is that not correct? I package plplot, and plplot-devel contains: # cat /usr/lib/pkgconfig/plplotd.pc prefix=/usr exec_prefix=/usr libdir=/usr/lib includedir=/usr/include/plplot drvdir=${libdir}/plplot5.6.1/driversd Name: PLplot Description: Scientific plotting library (double precision) Requires: Version: 5.6.1 Libs: -L${libdir} -lplplotd -L/usr/lib -lqhull -L/usr/lib -lcsironn -ldl -lm -L/usr/lib -lcsirocsa -lz -L/usr/lib -lfreetype Cflags: -I${includedir} But there are no dependencies on qhull-devel (via libqhull.so) and so forth. Should there be? -- Orion Poplawski System Administrator 303-415-9701 x222 NWRA/CoRA Division FAX: 303-415-9702 3380 Mitchell Lane orion(a)cora.nwra.com Boulder, CO 80301 http://www.cora.nwra.com

5 7

Removing of unwanted compiler flags from $RPM_OPT_FLAGS
by Jochen Schmitt 12 Sep '06

12 Sep '06

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello, becouse I have to find out, that some packages like blender have trouble if you are specify $RPM_OPT_FLAGS I have tried to search a method to remove selected compiler options from $RPM_OPT_FLAGS. My suggestion to solve this problem you may find at http://www.fedoraproject.org/wiki/JochenSchmitt/RemoveCFlagsFromRpmOptFlags… I will be happy for any comment and improvements. Best Regards: Jochen Schmitt -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.0.2 (Build 2424) iQA/AwUBRQWfq09gByurcX4MEQJ6sgCg2XjHBWBAJww22r44/5RhqiP6JIAAoI+K PRZSyaFRredlXj4YLKXW2XwC =jsLk -----END PGP SIGNATURE-----

4 3

SELinux testing
by James Morris 11 Sep '06

11 Sep '06

Many packages are not being tested with SELinux enabled before release, which is increasing the number of software defects being shipped, and causing users to disable SELinux. It is well documented that the cost of fixing software defects rises dramatically the further from the source they are experienced, and the worst possible case is after the software is shipped and deployed. For Fedora, these costs can be thought of in terms of cost to the project's goodwill and cost of everyone's time dealing with usually trivially addressable SELinux policy issues. Given that SELinux is a core security feature of the OS, enabled by default, I'd like to propose that the Fedora project establishes a simple guideline for package maintainers in relation to SELinux testing. This guideline would request that developers test their package with SELinux enabled (and by this I mean in enforcing mode) and follow a simple procedure: 1. Ensure they have the latest SELiunx policy installed. 2. Boot with selinux=1 and in enforcing mode. 3. Perform the normal testing of their application. 4. Check syslog (or /var/log/audit/audit.log if audit is enabled) for AVC messages related to their package. If there are any bugs or AVC messages: 5. Obtain support from the SELinux team. The best way to do this I believe is to file a bugzilla against the selinux-policy package. They should note that they are a Fedora packager (and expect a high priority response). If SELinux is running all or most of the time, issues will be caught and fixed eariler in their dev cycle. 6. Don't release the package until the SELinux issue is resolved. 7. If for some reason, #2 is not possible, and the release of the package is important enough to warrant disabling a core security feature of the OS: 7a. Make a note of the bugzilla # from (1) in the rpm info, cvs commit and release notes, with an explanation. Also include a standardized disclaimer in the rpm info which advises the user of the security risks arising from disabling SELinux. This should only happen in truly exceptional cases. I'm not sure how we can reliably notify users that SELinux can be re-enabled again, and whether they'll tolerate the entire fs being relabeled on reboot. Really, this just should not happen. Perhaps we can establish some kind of approval scheme for releasing a package which requires SELinux to be disabled (or for that matter, any security feature). Thoughts? -- James Morris <jmorris(a)redhat.com>

8 12

Importance of debuginfo packages
by Jason L Tibbitts III 11 Sep '06

11 Sep '06

Often when doing package reviews I find a package that needs some hack in order to get rpmbuild to build a complete debuginfo package. Some of this relates to passing the proper compiler flags and making sure the package doesn't strip its own binaries, which I think is necessary, but occasionally rpmbuild needs the source to be moved around in the build tree, or it needs symlinks flattened or somesuch. These are just hacks to work around rpmbuild deficiencies, and I can understand if packagers are reticent to clutter up their packages for something of unknown value. So, how important is it to have a proper debuginfo package? How much hacking is permissible or necessary in order to achieve that goal? Is an incomplete debuginfo package (that contains, say, the striped debug information but is missing some or all of the source code) still useful, or would it be better to have none at all? - J<

7 10

%makeinstall - must not or should not use it?
by Till Maas 11 Sep '06

11 Sep '06

Hiyas, the Packaging Guidelines contradict itself about the usage of %makeinstall http://fedoraproject.org/wiki/Packaging/Guidelines#head-fcaf3e6fcbd51194a5d… The headline says "Why the %makeinstall macro should not be used" and the first sentence says "RPM, as included in Fedora, includes a %makeinstall macro, but you must NOT use this macro in Fedora packages." It seems to be used by a lot of maintainers, so is this just a should not or is this another candidate for a major specfile-cleanup project? Regards, Till

11 17

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

packaging September 2006