packaging July 2006

packaging@lists.fedoraproject.org

32 participants
29 discussions

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

04 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

--vendor fedora, rationale/motivation?
by Rex Dieter 29 Nov '06

29 Nov '06

Per http://fedoraproject.org/wiki/Extras/FedoraDesktopEntryGuidelines: The vendor prefix (desktop-file-install --vendor=...) must be set to fedora". I don't understand the rationale/motivation behind requiring '--vendor fedora' I can, however, see that desktop-file-install's current implementation(*) of prepending %{vendor}- to the .desktop file name has some problems/issues: 1. .desktop filename now varies from upstream 2. --vendor may change when/if Extras bits are pulled into Core and/or RHEL. 3. *In particular*: when users start employing menu editors, since most(all?) of them base their customizations on the .desktop file name. -- Rex (*) If desktop-file-install's implementation instead followed something like kde's practice of using a vendor directory (e.g. /usr/share/applications/kde), then (1) and (3) would no longer be an issue.

4 6

Re: atrpms kernel modules
by Axel Thimm 16 Aug '06

16 Aug '06

On Tue, Jul 18, 2006 at 01:59:34PM +0200, Eric Tanguy wrote: > > kernels=`rpm -qf /boot/vmlinuz-* | grep -v "^file .* is not owned by any package"` > > uname_rs=`rpm -ql $kernels | grep ^/boot/vmlinuz- | sed -e's,^/boot/vmlinuz-$.*$$,\1,'` > > for kmdl in `rpm -qa \*kmdl\* | sed -e's,-kmdl-.*,-kmdl,' | sort -u`; > > do > > for uname_r in $uname_rs; do > > package=${kmdl}-$uname_r > > rpm -q $package > /dev/null 2>&1 || echo $package > > done > > done | xargs -r smart install -y > > Ok this script seems to use smart. is it working with yum ? Yes, I think "smart install -y" -> "yum -y install" is the only change needed. And for apt it would be "apt-get -y install". > How is this problem handled by livna because it works fine using > this repo : the kernel modules are installed and not updated > It's known that there are issues with this scheme, or any scheme > that will merge module and kernel versions. rpm for one can't cope with it. Suppose you have two active kernels (say 2.6.16 and 2.6.17 or xen0 and non-xen0 etc.) and already have foo-kmdl for both in version 1. Now foo-kmdl in version 2 is released. Both rpm -i (coinstall, no replacement of of foo-kmdl for the same kernel) and rpm -U (remove all foo-kmdl but the highest one, e.g. at least one kernel stay w/o any kmdl) won't work. yum/smart/apt can be tought to be more clever than rpm and try to do the proper thing, which they will only be able to do if the merged versions are distangled again, e.g. hidden in Provides: and the like. So in order for a merged-version scheme to work there is special handling neccessary (and for atrpms' system, too, but read on). I prefer to have rpm itself already do something sensible and since it can only upgrade one versioning system (e.g. either the kernel's or the module's) it's preferable to allow it to upgrade the module within the same kernel and not touch the cross-kernel boundaries. "No harm done" like accidentially removing kmdls for other kernels or coinstalling several kmdls for the same kernel. You "only" need to reinstall the missing kmdl upon each kernel upgrade. It's far easier to get this into the brains of yum/smart/apt (e.g. translate the 9 lines of bash above into plugings/hooks for these depsolvers) or simply use the 9liner above than have a scheme which is broken at the level of rpm. Incidentially one on my personal targets is to get thie discussed in the fedora packaging group and review the currently scheme. Of course, I'm proposing adoption of ATrpms' kmdl scheme :) http://www.fedoraproject.org/wiki/Packaging/GuidelinesTodo > when i install a new kernel and are removed when the kernel is > removed. How the dependencies to the kernel are installed (which is responsible for having an automatic removal on kernel removal) is a different story, which the version merging does not break. The issue is with the system (system=rpm and(or any higher depsolver tool, e.g. yum/smart/apt) being able to distinguish different foo-kmdls as _upgrades_ vs _coinstalls_. -- Axel.Thimm at ATrpms.net

11 63

missing this week's meetings
by Tom Callaway 09 Aug '06

09 Aug '06

Due to the fact that I will be on a plane somewhere between California and Illinois on Thursday, I will not be able to attend this week's Packaging or FESCo meetings. ~spot -- Tom "spot" Callaway: Red Hat Technical Team Lead || GPG ID: 93054260 Fedora Extras Steering Committee Member (RPM Standards and Practices) Aurora Linux Project Leader: http://auroralinux.org Lemurs, llamas, and sparcs, oh my!

6 10

COPYING (license) not under docdir
by Axel Thimm 31 Jul '06

31 Jul '06

Hi, I'm reviewing a package where the license file is under %{_datadir} beacuse the gtk GUI needs to display it. Moving it to %doc is bad as the application would be dependent on %doc content. But not having it in %doc is bad, too, as this is the canonical place someone will query the license text. IMHO in this case it should be doubled. Do you agree? -- Axel.Thimm at ATrpms.net

7 10

missing this week's IRC meeting(s)
by Rex Dieter 31 Jul '06

31 Jul '06

FYI, I'll be on vacation the latter part of this week, so I won't be able to attend this week's Packaging or FESCo meetings. -- Rex

1 0

PHP guidelines
by Jason L Tibbitts III 27 Jul '06

27 Jul '06

So, is there still any interest in PHP guidelines at all? I worked up http://fedoraproject.org/wiki/PackagingDrafts/PHP but then Ville had an idea for a template that doesn't need any special macro definitions to be provided by the php-pear package. I don't know what the current state of things is. Is there any chance of making any forward movement soon? We're going to start losing packagers if we can't get some reviews done soon. Regarding PECL modules, I looked over the php-pecl-xdebug package which is the only PECL module under review currently. The spec is clean and requires two macros which I have in the above draft, although the means for determining the API version is completely different. Could someone comment on the differences and relative strengths of: %define php_apiver %((phpize --version 2>/dev/null || echo 'PHP Api Version: 20041225' ) | sed -n '/PHP Api Version/ s/.*: *//p') and %define php_apiver %((echo 0; php -i 2>/dev/null | sed -n 's/^PHP API => //p') | tail -1) besides the obvious additional complexity of the former (and the hilarity of having to do such gymnastics in the first place)? - J<

8 22

BuildRoot
by Matthias Saou 26 Jul '06

26 Jul '06

Hi, Two quickies : 1) The current "preferred" BuildRoot which executes "id -u" isn't useful when used with mach or mock. I have nothing against it, I just don't feel the need to use it... as it's "preferred", I should be able to still use any BuildRoot value I want, right? I really simply prefer the same, but without forking a useless "id -u" execution. Yet another discussion about this here : https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=188461 (nearly all my review requests change into debates regarding useless details... I'm surprised that no one has yet criticized the non-aligned header lines I use ;-)) If the "preferred" term is changed to "mandatory" in the guidelines, I will abide, but continue thinking it's plain silly, and this brings us to... 2) Why the heck is there still the need for BuildRoot to be defined in each and every spec file we have!? Could we once and for all push a sane default value into FC6 and start considering removing it once and for all from all spec files by the time we reach FC10 or so? Currently, if BuildRoot isn't defined, then "" is used (thus the system's "/")... years ago this might have made sense for someone, but nowadays I really don't think so. Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 5.90 (Test) - Linux kernel 2.6.17-1.2431.fc6 Load : 1.14 0.60 0.47

8 45

Advice sought on a package currently under review
by Paul F. Johnson 25 Jul '06

25 Jul '06

Hi, I'm currently reviewing libpano12. It's GPL and the version supplied doesn't break any patents due to a change. However, I've asked the person who has submitted the package how simple it would be to alter the code to break the patent and it's incredibly easy. Could someone advise me how to proceed with this package? I know how anal they are in the US over patents (if they exist or not sometimes!) and don't want to land in any hot water. The BZ ref is #200064 TTFN Paul P.S. Given I'm currently reviewing, am I able to sponsor or is that something that is decided elsewhere? The packager on this bug is unsponsored. -- "Logic, my dear Zoe, is merely the ability to be wrong with authority" - Dr Who

3 6

Extras packages violating versioning schemes
by Michael Schwendt 22 Jul '06

22 Jul '06

From all packages in Extras, the following "Release" tag styles are chosen: Type pre-release : 47 Type %define rel : 1 Type %define release : 2 Type %define RELEASE : 0 Type normal : 1882 The following packages violate the versioning scheme for pre-releases: devel/azureus/azureus.spec Release: 0.20060529cvs_1%{?dist} devel/libapreq2/libapreq2.spec Release: 0.rc4.1%{?dist} devel/moin-latex/moin-latex.spec Release: 0.20051126.2%{?dist} devel/ktrack/ktrack.spec Release: 13.rc1%{?dist} devel/net6/net6.spec Release: 4.%{_rc}%{?dist} Should be Release: 0.1.20060529cvs%{?dist} Release: 0.1.rc4%{?dist} Release: 0.2.20051126%{?dist} Release: 0.13.rc1%{?dist} Release: 0.4.%{_rc}%{?dist} but that's impossible now. My version-bump script caught these, when I started porting it from Perl to Python. And I haven't made it examine the 1882 "normal" release tags yet. ;) Well, a few odd cases which I have not classified yet: Release: 2.0%{?dist} Release: 2.6%{?dist} Release: 5.20041017%{?dist} Release: 0.s11.9%{?dist} Release: 0.pre2%{?dist} Release: 9.%{releasename}%{?dist} Release: 1%{?pre:.%{pre}}%{?dist} Release: 3.FC4 Release: 3.2%{?dist} Release: 2.6.3.2.2%{?dist} Release: 0%{?nm_vpnc_cvs_version}.1%{?dist} Release: 0.%{ghdlsvnver}svn.2%{?dist} Release: 1%{?prerelease:.%{prerelease}}%{?dist}

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

packaging July 2006