Statistics on usage of disttags in Fedora Core and Extras
by Axel Thimm
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
17 years
UTF-8 Encoding update
by Toshio Kuratomi
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
17 years
-devel arch dependencies
by Orion Poplawski
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
17 years
Fedora Packaging Committee Meeting Time Change
by Tom Callaway
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
17 years
Unadressed bugs as part of reviews
by Toshio Kuratomi
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
17 years
[Fwd: Re: [CMake] cmake does not set execute bit on shared libraries]
by Orion Poplawski
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
17 years
exemptions for .la files in some -devel packages ?
by Jeremy Hinegardner
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
17 years
rpm output guidelines
by Christopher Stone
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.
17 years
