packaging April 2007

packaging@lists.fedoraproject.org

34 participants
21 discussions

Statistics on usage of disttags in Fedora Core and Extras
by Axel Thimm 16 Apr '07

16 Apr '07

Hi, I checked on the percentage of how many packages do use disttags these days. And since I was at it I did some historical reseach to see the tendency (I don't have access to Pre-Extras, so the Extras and Sum slots for FC1 and FC2 are empty). The results are quite interesting: release Fedora Core Fedora Extras Sum 1 2 / 936 <1% 2 0 / 947 0% 3 9 / 970 1% 711 / 1115 64% 720 / 2085 35% 4 12 / 965 1% 1530 / 1786 86% 1542 / 2751 56% 5 36 / 1157 3% 2686 / 2778 97% 2722 / 3935 69% 6 336 / 1154 29% 3008 / 3068 98% 3344 / 4222 79% rawhide 846 / 1218 69% 2833 / 2897 98% 3679 / 4115 89% Some notes: o Fedora Extras has always used more packages w/ disttags than w/o, the tendency up to its last incarnation in FC6 was steadily increasing until it reached 98% and remained at that level. o Fedora Core has adopted disttags very late in comparison to Fedora Extras, but also has the steepest growth - since FC6 every third package has already been disttag'ed, by F7 it's more than two thirds. This is mostly due to the fact that previously the Fedora Core buildsystem would not support setting the disttag macros, while the Fedora Extras buildsystem did so for the very beginning. o In their sum the disttagged packages have also reached the majority since FC4. Conclusions: o The disttag idiom was very successful, even though it is not mandatory it managed to be adopted in over 98% of Fedora Extras and 69% of Fedora Core. o From EPEL's POV, since it is a Fedora Extras rebuild for RHEL the package pool comes from the 98% of disttagged packages. Although RHEL is smaller than Fedora Core and one would assume some packages in EPEL coming from Fedora Core and thus getting at a lower than 98% share, current EPEL shows that almost all packages but some special ones like epel-release use the disttag. o For any other application that would require mandatory disttags like for example disttags of fc7.89, fc7.90 etc for rawhide and test releases this setup is not very far away. Looking at the sum of packages, this could happen by F8 by itself (the sum gains at least 10% each year and there are only 11% left). Suggestions: o watch the tendency and when it really reaches about 100% (e.g. F8) think about what gains mandatory disttags could bring us. If it is worth it fix the remaining few packages to use disttags (note: not all packages make sense to carry one, firmwares or XXX-release packages for example don't really need them) o continue suggesting the use of disttags to new packagers - even though optional it should be the recommended way to package things up. -- Axel.Thimm at ATrpms.net

12 49

UTF-8 Encoding update
by Toshio Kuratomi 14 Apr '07

14 Apr '07

Hey, After some correspondence with Nicolas Mailhot on -maintainers, we arrived at some updated wording for UTF-8 (Encoding and Filename). Do we need to approve the wording changes? If so it would be nice to vote on list as I don't think there's any changes to the spirit of the guideline, just clarifications in language:: == Encoding == Unless you need to use characters outside the [http://commons.wikimedia.org/wiki/Image:Ascii_full.png ASCII repertoire], you will not need to be concerned about the encoding of the spec file. If you do need non-ASCII characters, save your spec files as UTF-8. If you're in doubt as to what characters are ASCII, please refer to [http://commons.wikimedia.org/wiki/Image:Ascii_full.png this chart]. === Non-ASCII Filenames === Similarly, filenames that contain non-ASCII characters must be encoded as UTF-8. Since there's no way to note which encoding the filename is in, using the same encoding for all filenames is the best way to ensure users can read the filenames properly. If upstream ships filenames that are not encoded in UTF-8 you can use a utility like convmv (from the convmv package) to convert the filename in your %install section. -Toshio

5 4

-devel arch dependencies
by Orion Poplawski 12 Apr '07

12 Apr '07

Here's a question. Should -devel package requirements be of the form: Requires: package-devel.%{arch} I ask because of the following: # yum list libX11-devel Loading "installonlyn" plugin Setting up repositories Reading repository metadata in from local files Excluding Packages from Fedora Core 6 - x86_64 - Updates Finished Installed Packages libX11-devel.i386 1.0.3-6.fc6 installed Available Packages libX11-devel.x86_64 1.0.3-7.fc6 updates libX11-devel.i386 1.0.3-7.fc6 updates [root@apollo ~]# rpm -e libX11-devel error: Failed dependencies: libX11-devel is needed by (installed) libXpm-devel-3.5.5-3.x86_64 libX11-devel is needed by (installed) libXt-devel-1.0.2-3.1.fc6.x86_64 libX11-devel is needed by (installed) libXmu-devel-1.0.2-5.x86_64 libX11-devel is needed by (installed) libXext-devel-1.0.1-2.1.x86_64 libX11-devel is needed by (installed) mesa-libGL-devel-6.5.1-9.fc6.x86_64 libX11-devel is needed by (installed) libXpm-devel-3.5.5-3.i386 libX11-devel is needed by (installed) libXt-devel-1.0.2-3.1.fc6.i386 libX11-devel is needed by (installed) libXext-devel-1.0.1-2.1.i386 Should the libXpm-devel-3.5.5-3.x86_64 requirement for "libX11-devel" be satisfied by libX11-devel.i386? The needed libraries won't be there for linking. Can this be done in packaging, or does this need to be done in rpm? -- Orion Poplawski Technical Manager 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

13 35

Fedora Packaging Committee Meeting Time Change
by Tom Callaway 12 Apr '07

12 Apr '07

Since some of the folks on the Committee have trouble attending our weekly meetings at 1700 UTC, I propose that we move it up an hour to 1600 UTC. FPC members, please vote. I'd like this to be unanimous. :) ~spot

9 18

Unadressed bugs as part of reviews
by Toshio Kuratomi 09 Apr '07

09 Apr '07

I saw this set of comments in a merge review and it struck me as a little off: > 5. There are outstanding bugs for [pkg] please address them. This is not relevant to the packaging review process. I see two problems with the above statements: 1) The reviewer is not specifying a specific problem that they consider a blocker for approval of the package. 2) The packager is not acknowledging that potential problems with the runtime of the package are relevant to the review. Perhaps we need to have some statement of reviewers' and packagers' responsibilities at the top of the Guidelines: "It is the reviewer's responsibility to point out specific problems with a package and a packager's responsibility to deal with those issues. The reviewer and packager work together to determine the severity of the issues (whether they block a package or can be worked on after the package is in the repository.) The Packaging Guidelines are a collection of common issues and the severity that should be placed on them. If a reviewer or packager believe their package reveals a flaw in the Guidelines, examples of how the rule is failing should be brought to the attention of the Packaging Committee so they can consider whether the rule has unanticipated consequences and modify it to better fit all situations." [1]_ Let me know what you think of having such a statement in general and this wording in particular. [1]_: http://fedoraproject.org/wiki/PackagingDrafts/OverallReviewGoals -Toshio

2 3

[Fwd: Re: [CMake] cmake does not set execute bit on shared libraries]
by Orion Poplawski 09 Apr '07

09 Apr '07

Some interesting information about the shared library execute bit issue. Why is it that we require the execute bit? I found an old post about it maybe being tied to the kernel protecting overwriting running programs, but no idea if that ever was put it place. -- Orion Poplawski Technical Manager 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

6 8

exemptions for .la files in some -devel packages ?
by Jeremy Hinegardner 09 Apr '07

09 Apr '07

Hi all, I'm doing a couple of Merge Reviews for apr[1] and apr-util[2] and there seems to be an issue over the inclusion of the .la files in the apr-devel and apr-util-devel rpms. According to the Review Guidelines .la files are NOT allowed, but I have been informed via the bugzilla tickets that the .la files in these packages are required and cannot be removed. I do not have enough insight on libtool archives to render a decision here, so from my perspective, it appears that one of two things must happen: 1) There needs to be a clarification in the Review Guidelines regarding .la files that there are rare(?) instances where .la files are required and either list them or bring them up on a case-by-case basis to this list. 2) There is a misunderstanding from the packagers perspective on this issue. I'm initially assuming that the former is the correct approach here and just want to get confirmation from the list, as I'm probably newer than most at this process. enjoy, -jeremy [1] - https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=225253 [2] - https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=225254 -- ======================================================================== Jeremy Hinegardner jeremy(a)hinegardner.org

4 4

rpm output guidelines
by Christopher Stone 06 Apr '07

06 Apr '07

Why is my console littered with tons of output when I update selinux-policy-targeted rpm? I get tons of crap spewed out to my console. Aren't there any guidelines to prevent packages from doing this, and if not can we please make some? Wouldn't it be great if all this garbage output went to some place nice like syslog? selinux-policy-target puke: /sbin/restorecon reset /etc/cron.daily/000-delay.cron context system_u:object_r:etc_t:s0->system_u:object_r:bin_t:s0 /sbin/restorecon reset /etc/cron.daily/00webalizer context system_u:object_r:etc_t:s0->system_u:object_r:bin_t:s0 /sbin/restorecon reset /etc/cron.daily/0anacron context system_u:object_r:etc_t:s0->system_u:object_r:bin_t:s0 /sbin/restorecon reset /etc/cron.daily/beagle-crawl-system context system_u:object_r:etc_t:s0->system_u:object_r:bin_t:s0 /sbin/restorecon reset /etc/cron.daily/certwatch context system_u:object_r:etc_t:s0->system_u:object_r:bin_t:s0 /sbin/restorecon reset /etc/cron.daily/cups context system_u:object_r:etc_t:s0->system_u:object_r:bin_t:s0 /sbin/restorecon reset /etc/cron.daily/logrotate context system_u:object_r:etc_t:s0->system_u:object_r:bin_t:s0 /sbin/restorecon reset /etc/cron.daily/makewhatis.cron context system_u:object_r:etc_t:s0->system_u:object_r:bin_t:s0 /sbin/restorecon reset /etc/cron.daily/mlocate.cron context system_u:object_r:etc_t:s0->system_u:object_r:bin_t:s0 /sbin/restorecon reset /etc/cron.daily/prelink context system_u:object_r:etc_t:s0->system_u:object_r:bin_t:s0 /sbin/restorecon reset /etc/cron.daily/rpm context system_u:object_r:etc_t:s0->system_u:object_r:bin_t:s0 /sbin/restorecon reset /etc/cron.daily/tmpwatch context system_u:object_r:etc_t:s0->system_u:object_r:bin_t:s0 /sbin/restorecon reset /etc/cron.hourly/mcelog.cron context system_u:object_r:etc_t:s0->system_u:object_r:bin_t:s0 /sbin/restorecon reset /etc/cron.monthly/0anacron context system_u:object_r:etc_t:s0->system_u:object_r:bin_t:s0 /sbin/restorecon reset /etc/cron.weekly/0anacron context system_u:object_r:etc_t:s0->system_u:object_r:bin_t:s0 /sbin/restorecon reset /etc/cron.weekly/makewhatis.cron context system_u:object_r:etc_t:s0->system_u:object_r:bin_t:s0 Do I really need to know all this? Because personally I have absolutely no idea what all this garbage means.

2 1

license for concurrent package
by Permaine Cheung 04 Apr '07

04 Apr '07

Hi, The concurrent package in core has stated the following (under the Notes section of its URL http://gee.cs.oswego.edu/dl/classes/EDU/oswego/cs/dl/util/concurrent/intro.…): 'All classes are released to the public domain and may be used for any purpose whatsoever without permission or acknowledgment. Portions of the CopyOnWriteArrayList and ConcurrentReaderHashMap classes are adapted from Sun JDK source code. These are copyright of Sun Microsystems, Inc, and are used with their kind permission,' (link is http://gee.cs.oswego.edu/dl/classes/EDU/oswego/cs/dl/util/sun-u.c.license.p…) And further down from that page it states: 'Do I need a license to use it? Can I get one? No!' Is this okay? Thanks, Permaine

3 3

Missing today's meeting
by Axel Thimm 03 Apr '07

03 Apr '07

Hi, I won't be able to make the meeting today. -- Axel.Thimm at ATrpms.net

3 3

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

packaging April 2007