packaging December 2006

packaging@lists.fedoraproject.org

36 participants
27 discussions

Conflicts Draft Proposal
by Tom Callaway 11 Jan '07

11 Jan '07

I drafted a proposal for when it is ok to use Conflicts: (almost never): http://fedoraproject.org/wiki/PackagingDrafts/Conflicts Keep in mind that while it is not stated in the Draft, the kernel is considered a special case, and I feel strongly that most (if not all) of its existing Conflicts: will be approved. Fedora Packaging Committee Members should vote via email on this issue, as we did not have quorum in the IRC meeting to vote. ~spot

16 26

Request to drop %(%{__id_u} -n) in preferred buildroot
by Axel Thimm 05 Jan '07

05 Jan '07

Hi, I think the `preferred buildroot' is not really making sense. The above has developed historically out of a misunderstanding in ancient buildroot times. When people were building as root and BuildRoots were defined as %{_tmppath}/%{name}-%{version}-root, some considered "root" to mean the uid of the builder. Later %release was added and some replaced root with `id -un`. Even later some realized that root was referring to the BuildRoot and in order to play safe added both. I'm using %{_tmppath}/%{name}-%{version}-%{release}-root in my packages and someone is now nitpicking on why not using the preferred BuildRoot as given in the guidelines. Instead of locally fighting a BuildRoot battle, I'd better get the guidelines fixed ;) Also consider what this really is about: Deambiguifying the BuildRoot per package makes sense as there may be several build processes sharing the same filesystem (either locally or through NFS), but deambiguifying the build user, too, means that we assume that the same EVR package will be possibly built on the same filesystem by different users? And even simultaneously? It makes more sense to include a conditional epoch or target/arch in the buildroot that the builder. In fact the best thing for a buildsystem is to override the buildroot adding a build-id to it anyway. -- Axel.Thimm at ATrpms.net

10 23

iconcache, v0.5
by Rex Dieter 01 Jan '07

01 Jan '07

FYI, updated iconcache proposal v0.5: * nixed xdg-utils. * Updated motivations/justifications, * gtk2 implementation suggestions/links, http://fedoraproject.org/wiki/PackagingDrafts/ScriptletSnippets/iconcache Looks like Core folks won't settle for anything in between status-quo and 100% fix (no in-between-compromising like using xdg-utils), so let's give it a shot. This time round, I'll try to put all relavent suggestions, comments, dialog on the wiki. Hopefully, that will help keep those not following the intimate details of the ml threads informed. -- Rex

8 33

Packaging/PHP : add channels packaging proposal.
by Remi Collet 29 Dec '06

29 Dec '06

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Here is another update proposal for the PHP Guidelines. Context : some packages are provided on other channels than the default one (pear.php.net) The channel definition must be installed (in the pear registry) to allow the build, so this require an RPM of channel definition available in the repository : - - to build the package in mock. - - to install the package Note : i don't keep Requires php, as php-pear already require php and php-cli. Regards. - --------------------------------------------------------- ==Naming scheme== * CHANNEL definition packages should be named php-channel-channelname-%{version}-%{release}.noarch.rpm ==Requires and Provides== CHANNEL definition Packages * Requires: php-pear(PEAR) * Provides: php-channel(channelname) PEAR Packages * Requires: php-pear(PEAR) * Requires: php-channel(channelname) if needed * Provides: php-pear(foo) or php-pear(channelname/foo) ==Macros and scriptlets== CHANNEL definition %post if [ $1 -eq 1 ] ; then %{__pear} channel-add %{pear_xmldir}/%{channel_name}.xml > /dev/null || : else %{__pear} channel-update %{pear_xmldir}/%{channel_name}.xml > /dev/null ||: fi %postun if [ $1 -eq 0 ] ; then %{__pear} channel-delete %{channel_name} > /dev/null || : fi -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFFlVpJYUppBSnxahgRArDEAJ4jSt5d9UNxgnCldXdApC9fyg8L2wCg3H/z yojj8Exk1QfwtjqBtkJ4GKg= =Qb6D -----END PGP SIGNATURE-----

1 0

(Un)packaging partly patented software
by Axel Thimm 28 Dec '06

28 Dec '06

Hi, I think I had read somehwere, or we just discussed it (?), that for tarballs carrying potential patent infringing bits it is not enough to build/package the other parts, but that also the src.rpm needs to be kept clean. E.g. the upstream tarball needs to be unpacked, the patent encumbered bits removed/patched out and the result repackaged into a new tarball (for example into foo-1.2-patentfree.tar.gz) Am I remembering correctly? Do we have something like a procedure in the wiki on creating these modified tarballs and commenting the specfile approriately (I couldn't find anything when searching for "patents", but there were perhaps too many hits ...). If not shouldn't we come up with one? The procedure needs to be documented and be reproducable for reviewers to be able to confirm that the tarball "matches" upstream indeed, since they won't have any nice md5sum method to compare. -- Axel.Thimm at ATrpms.net

2 1

Packaging/PHP : some update proposal
by Remi Collet 27 Dec '06

27 Dec '06

Here is some updates proposal for the Guidelines for packaging PHP addon modules 1 ------ No file in BUILD directory PEAR & PECL Packages The source archive contains a package.xml outside any directory, so you should/must use %setup -q -c 2 ----- Initial spec. PEAR Packages To create your specfile, you could use the default template provided by rpmdevtools or generate one with the command "pear make-rpm-spec Sources.tgz" (install php-pear-PEAR-Command-Packaging) 3 ---- API version check PECL Packages With php-5.1.6-3.3 on FC6 and php-5.2.0-8 on rawhide php-common now provide php-zend-api. This exact version must be require by pecl extension. The php-common in Fedora Core 7 and above (version 5.2.0-8) provides several useful macros: %{php_core_api} %{php_zend_api} %{php_pdo_api} Solution 1 (using the macros, only available on rawhide) %if %{?php_zend_api}0 Requires: php_zend_api = %{php_zend_api} %endif Solution 2 (not using the /etc/rpm/macros.php) %global php_zendapi %((echo 0; php -i 2>/dev/null | sed -n 's/^PHP Extension => //p') | tail -1) %if %{fedora} >= 6 Requires: php_zend_api = %{php_zendapi} %endif We can also post a RFE on php to also provide the macros on FC6 --- Some comments. A load time, PHP check that each extension is compatible. php_dl.c compare ZEND_MODULE_API_NO value at php build time and at extension build time. If this values doesn't match, the extension is not loaded and an error is displayed : > PHP Warning: PHP Startup: mailparse: Unable to initialize module > Module compiled with module API=20060613, debug=0, thread-safety=0 > PHP compiled with module API=20050922, debug=0, thread-safety=0 > These options need to match > php-abi (PHP_API_VERSION) is 20041225 for a very long time. php-zend-abi (ZEND_MODULE_API_NO) is the true API version need to check extension compatibility Ex : php-5.1.4, 5.1.5, 5.1.6 PHP Api Version: 20041225 Zend Module Api No: 20050922 php-5.2.0 PHP Api Version: 20041225 Zend Module Api No: 20060613 See Bugzilla #212804 Requires: php-api could be keep, but is not very useful Thanks for your comments, I could edit the wiki if this is approved and if you want me to do it. Remi. P.S. i hope this is clear ?

1 1

Proposal to limit file deps
by Toshio Kuratomi 22 Dec '06

22 Dec '06

Hey all, I've just added a draft proposal for limiting file dependencies in packages. It's a "should" recommendation at this point. http://www.fedoraproject.org/wiki/PackagingDrafts/FileDeps = File Deps Guideline = == Problem == Resolving file dependencies can be a bottleneck when running yum. With our current repodata format, information on which package owns files in /etc and the bin directories (/bin /sbin /usr/bin /usr/sbin) are kept in primary.xml. All other file deps are kept in filelist.xml. This means that anytime yum has to resolve a file dep in /etc or a bin directory it can just download primary.xml to resolve it. If the file dep is outside of those directories, yum has to download and parse a second xml file, filelist.xml, which is much larger than primary.xml. Fedora 6 repodata compressed and uncompressed: || ||primary.xml||filelist.xml|| ||Core ||1M/7.6M ||3.1M/39.2M|| ||Extras ||4.7M/11.7M ||4M/50.8M|| ||Updates||0.4M/4.2M ||2.1M/27.5M|| The compressed size has direct bearing on the additional time it will take to download the additional filelist.xml. The uncompressed size is one indicator of how much additional time is needed to parse for the file that satisfies the dependency. If yum does not need to refresh its primary.xml and filelist.xml (because it downloaded a copy previously and the repository has not been updated since), yum won't have to parse a new file and the filelist info will be quicker to find (as the file will have been parsed into an sqlite database), however this is the exception rather than the rule. If we can avoid having to download and parse filelist.xml, we can greatly speed up yum's dependency resolution times. == Proposed Guideline == '''SHOULD''': If the package has file dependencies outside of /etc, /bin, /sbin, /usr/bin, or /usr/sbin consider requiring the package which provides the file instead of the file itself. Using file dependencies outside of /etc, /bin, /sbin, /usr/bin, or /usr/sbin requires yum (and other depsolvers using the repomd format) to download and parse a large xml file looking for the dependency. Helping the depsolvers avoid this processing by depending on the package instead of the file saves our end users a lot of time. -Toshio

10 21

printing textual messages in %post etc.?
by Ralf Corsepius 21 Dec '06

21 Dec '06

Hi, Do the GuideLines/Does the FPC have an opinion on rpms intentionally printing out textual messages during installs? At least, I could not find a corresponding paragraph in the GuideLines. Background: tripwire's spec (Currently under review) contains this: %post ... # Print getting started help message if [ $1 -eq 1 ]; then echo To configure tripwire, read: %_docdir/%{name}-%{version}/README.Fedora fi I don't have a strong opinion on this and actually am ambivalent. On one hand, such messages can be helpful to users. On the other hand, in general, rpm-installs should be silent as much as possible. Furthermore, I am not sure if printing such messages is safe. How does rpm handle such messages/ to which file descriptor will they be piped (stdout, stderr ...)? Will they desturb installers (yum, apt, shell scripts, pirut, yumex, synaptic, ...) and what happens with such messages during unsupervised installs? Ralf [1] https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=203864

5 5

Re: icon cache scriplet guideline update
by Rex Dieter 21 Dec '06

21 Dec '06

Rex Dieter wrote: > Callum Lerwick wrote: >> On Wed, 2006-12-20 at 07:43 -0600, Rex Dieter wrote: >>> Because, frankly, poo-pooing the current proposal/guidelines in favor >>> of some handy-wavy theoretical lacking-actual-implementation >>> solution, is no solution. >> >> Well, the point is, the current proposal does not address the "multiple >> packages needlessly updating caches multiple times" problem at all. > > Fair enough, I'll investigate hooking into rpm's %posttrans hooks. My > findings so far are promising. I formally withdraw the iconcache proposal as-is, pending investigation of the previously unaddressed "needlessly updating cache multiple times" issue. -- Rex

3 6

Java (jpackage) naming scheme rehash.
by Jesse Keating 20 Dec '06

20 Dec '06

A while ago we had a long discussion about the naming of jpackage packages within Fedora. Currently the naming convention that is used by Fedora for jpackage packages does not mesh with the Fedora Packaging Guidelines. See http://fedoraproject.org/wiki/PackagingDrafts/JavaPackageNaming There are a number of proposals on that page, but the one I'd like to focus on is http://fedoraproject.org/wiki/PackagingDrafts/JavaPackageNaming#Proposal_1 This changes how we number the Fedora spins of the jpackage packages, but doesn't introduce any extra chars into the version/release. Please, jpackage folks who are now on this list, review the page and the proposal and comment / suggest / flame / whatever. Please note that part of the core/extras merge, every package will be reviewed, and currently the jpackage packages (of which there are many, and some 90~ new ones pending for maven2) will not pass the review. Resolution on this matter is urgent. Thanks! -- Jesse Keating Release Engineer: Fedora

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

packaging December 2006