packaging March 2005

packaging@lists.fedoraproject.org

24 participants
23 discussions

perl module MODULE_COMPAT
by Warren Togami 05 Apr '05

05 Apr '05

Requires: perl(:MODULE_COMPAT_%(eval "`%{__perl} -V:version`"; echo $version)) As long as we're going through all FC4 perl modules, we might as well add this to all packages too. Just confirming, is this wanted in *ALL* packages that need perl, both regular arch and noarch? Warren Togami wtogami(a)redhat.com

5 14

dist tag revisited
by Tom Callaway 04 Apr '05

04 Apr '05

I had an insightful discussion with Sopwith this afternoon, and we discussed the idea of dist tags, and some important discussion arose: Elliot pointed out that for any given .src.rpm, the name-version-release needs to stay fixed for all builds of that .src.rpm. Otherwise it becomes impossible to track packages back to their source, keep an audit trail, etc. The problem with using the macros is that if a maintainer does 'make build' on an fc3 box, then they get the dist tag value from that machine in the n-v-r. When they go to check this into CVS (say, into the fc4 branch), its wrong. We don't want someone doing 'make tag' on the FC-4 branch and having n-v-r = foo-1.2-3.fc3. But at the same time, we also want to avoid forcing the packagers to have to put the dist value into the spec manually. This defeats the entire reason for dist tags, which is to have a single spec that can be used for multiple distributions. We discussed a lot of options, but Elliot came up with a good idea, which is best explained by giving an example of a new package commit: - I'm a maintainer, of package logjam. - I make a single spec for all possible fc builds using the documented "approved" dist macros - I set Release: 1 (note, no %{dist}) - I make my src.rpm. - I then run ./cvs-import.sh --use-dist --branch=fc4 logjam-1.0.0-1.src.rpm - The cvs-import script does the following: - Checks my spec to make sure that n-v-r doesn't have %{dist} in it already - Notes the value of the branch that I'm checking this package into - Uses that value and adds the following lines to the top of my spec %define fedora 4 %define dist .fc4 - Appends %{?dist} to the end of Release (so it becomes Release: 1%{?dist} ) - Commits the spec with the added defines into the branch. Now, with this mechanism, if I want to do multiple branches for a single spec, its easy, cvs-import.sh does the work for me. We keep a single n-v-r per branch, and there is no naming conflicts between branches. The branch-copy operations would just change the values of the macros, or add the macros near the top if they're not already in the .spec file. We'd want to add a check in the buildsystem to make sure that people haven't polluted the %{dist} defines, but that shouldn't be terribly difficult. Now, for people wanting to take their original spec and build it somewhere else, say for RHEL, we could use a set of rpm macros. Elliot and I worked on a simple shell script that parses /etc/redhat-release and returns (depending on the flag chosen): The version of RHEL for %{_el} (if on RHEL) The version of Fedora for %{_fedora} (if on Fedora) The version of RHL for %{_rhel} (if on RHL) The number of the distro for %{_distnum} The type of the distro for %{_disttype} The dist tag value for %{_dist} The macros then become as simple as: %_dist %{expand:%%(/usr/lib/rpm/redhat/dist.sh --dist)} %_distnum %{expand:%%(/usr/lib/rpm/redhat/dist.sh --distnum)} %_disttype %{expand:%%(/usr/lib/rpm/redhat/dist.sh --disttype)} %_rhel %{expand:%%(/usr/lib/rpm/redhat/dist.sh --el)} %_fedora %{expand:%%(/usr/lib/rpm/redhat/dist.sh --fc)} %_rhl %{expand:%%(/usr/lib/rpm/redhat/dist.sh --rhl)} The script is already checked into CVS for redhat-rpm-config. If you wanted to build off that spec for RHEL, you'd just need to add these 7 lines to your local .rpmmacros file. This provides a standardized, easy way to do single-spec, multiple distribution packaging. But of course, there are bound to be complications. Please ponder this implementation, and offer feedback. Thanks, ~spot -- Tom "spot" Callaway: Red Hat Sales Engineer || GPG Fingerprint: 93054260 Fedora Extras Steering Committee Member (RPM Standards and Practices) Aurora Linux Project Leader: http://auroralinux.org Lemurs, llamas, and sparcs, oh my!

5 5

Re: [Fedora-packaging] %{_libdir}/rpm/brp-compress for perl modules
by Alan Milligan 31 Mar '05

31 Mar '05

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Warren, Check out the Perl CPAN module, it knows all about how to query CPAN. There's also something called CPANPLUS, but I'm not sure if it evolved past CPAN or not. Also, can we consider NOT putting the perl modules into the 'vendor' directory - clearly they are vanilla ;) Cheers, Alan -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFCTC/sCfroLk4EZpkRAoqPAKCTEydWfON/gIbK63wmy54wf/Ms+ACgxhQI IGXpozBu2+ov9lackZ+6oFw= =sKJw -----END PGP SIGNATURE-----

2 1

%{_libdir}/rpm/brp-compress for perl modules
by Warren Togami 31 Mar '05

31 Mar '05

https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=127988 [ -x %{_libdir}/rpm/brp-compress ] && %{_libdir}/rpm/brp-compress There are several packages like this, and similar perl modules with /usr/lib instead of %{_libdir}. This fails to build on x86_64 for obvious reasons. While this isn't a problem for FC's build system (everything is built on 32bit), we should fix these packages. [ -x /usr/lib/rpm/brp-compress ] && /usr/lib/rpm/brp-compress While doing this would work, this may confuse people because our packaging docs say to macroize everything. Are there other cases where macroizing directories is NOT the right thing to do? And... any idea why these packages are running brp-compress anyway? Doesn't this happen automatically without it? Warren Togami wtogami(a)redhat.com

2 2

questions regarding kernel-devel and kernel-smp-devel packages
by Jef Spaleta 29 Mar '05

29 Mar '05

Currently in rawhide at the moment yum treats kernel-devel as installonly but kernel-smp-devel package is treated as a normal package when doing updates. Which is the more correct befault behavior? Do we want multiple versions of kernel-devel and kernel-smp-devel packages to be installed by default or do we want these packages to update? If we want multiple versions to install, as default behavior, do we want to use a different mechanism then the package name? Like using a common provides statement that yum can see and act on.. similar to how kernel and kernel-module packages are sensed? -jef

4 5

Running scriptlets only in certain situations
by Chuck Anderson 27 Mar '05

27 Mar '05

On http://fedoraproject.org/wiki/PackagingGuidelines under "Running scriptlets only in certain situations" it gives an example: This means that for example a package that installs an init script with the chkconfig command should uninstall it only on erase and not upgrade with the following snippet: %postun if [ $1 -eq 0 ]; then /sbin/chkconfig --del %{name} fi However, that example is incorrect. By the time %postun is run, the /etc/init.d/%{name} file is already gone. This needs to be run instead in %preun.

2 1

Alternative kernel packages
by Orion Poplawski 24 Mar '05

24 Mar '05

I'm starting to build alternative kernel packages based on the -ck patchsets, and am looking for some feedback/suggestions. My current spec changes from the kernel-2.6.spec (besides changing patches and configs) are: 32c34 < %define release %(R="$Revision: 1.1177 $"; RR="${R##: }"; echo ${RR%%?})_FC4%{rhbsys} --- > %define release %(R="$Revision: 1.1176 $"; RR="${R##: }"; echo ${RR%%?})_FC4%{rhbsys}.ck2 ^ add the version of the ck patch to the release. 155c157 < Name: kernel --- > Name: kernel-ck ^ change the name of the package to kernel-ck The goal here is to be able to completely remove all of the stock fedora kernels and only leave kernel-ck (much like I do on smp machines and leave only kernel-smp), and have a "desktop" kernel choice. Any other gotchas? The pipe dream would be to have a kickstart file tell anaconda to install the kernel-ck set. -- Orion Poplawski System Administrator 303-415-9701 x222 Colorado Research Associates/NWRA FAX: 303-415-9702 3380 Mitchell Lane, Boulder CO 80301 http://www.co-ra.com

2 1

Importing tetex packages question
by Jose Pedro Oliveira 23 Mar '05

23 Mar '05

Hi, Before importing the following tetex packages SRPMS - tetex-bytefield, tetex-xcolor, tetex-pgf. tetex-beamer - I would like to pose a question regarding the source file version control done by/in the CVS side cache (make upload FILES=...): Description of the problem: The source tarballs for the above tetex packages are all created on the fly by the DANTE CTAN master mirror. The main problem is that CTAN only has the latest version of every package and that the tarball generated has no version in its name (see for example: http://gsd.di.uminho.pt/jpo/software/RPMS/tetex-bytefield.spec). Although there is a possibility of finding versioned tarballs for some of the above packages, the problem remains for other CTAN Latex packages - no author homepage with versioned tarballs. Question: Should I manually had a version to the DANTE generated tarball? Or can the CVS accept a new tarball with the same name when a package update occurs (check thread below). Review request thread: https://www.redhat.com/archives/fedora-extras-list/2005-March/msg00869.html Thanks in advance, jpo -- José Pedro Oliveira * mailto: jpo(a)di.uminho.pt * http://gsd.di.uminho.pt/~jpo * * gpg fingerprint = F9B6 8D87 859D 1C94 48F0 84C0 9749 9EB5 91BD 851B *

2 4

Re: gnome-theme-clearlooks please Re: APPROVED: clearlooks
by Dag Wieers 21 Mar '05

21 Mar '05

On Mon, 21 Mar 2005, Warren Togami wrote: > Ignacio Vazquez-Abrams wrote: > > Sounds like a plan. Anyone have any complaints with the name? > > > > Also, I'd like to add "Obsoletes: clearlooks <= 0.5" to both packages > > temporarily for a couple of releases just to clean out packages that > > people may have been using from either my repo or self-builds from CVS. > > Any complaints? > > I would advise against it. We need to move forward with FC and FE as the > canonical package set. Whoever is using the old package name must manually > move. This is only a small number of people right? > > Plus this cancels the benefit of renaming this package in the first place, > because it already pollutes the namespace. Actually I would allow for something like this for eg. 1 release cycle. You can't take the userbase as a objective measurement because what is a big userbase ? Fact is, I have been using 'wrong' package names (to my liking) because I had to follow the naming scheme most likely to be adopted either by Red Hat or by fedora.us. So I had to try to be forward compatible. For this reason, the only possibility to have an upgrade path to Fedora Extras, 3rd party repositories rely on Obsolete tags. It would be a wrong signal if only an upgrade path from fedora.us to Fedora Extras is allowed, especially because 3rd party repositories have been the only alternative users had to turn to for extra packages. Since we have a more strict naming policy in place now, new naming mismatches are very limited so namespace pollution will slow down. Kind regards, -- dag wieers, dag(a)wieers.com, http://dag.wieers.com/ -- [all I want is a warm bed and a kind word and unlimited power]

1 0

Re: APPROVED: clearlooks
by Dag Wieers 21 Mar '05

21 Mar '05

On Mon, 21 Mar 2005, Ignacio Vazquez-Abrams wrote: > On Mon, 2005-03-21 at 21:24 +0100, Dag Wieers wrote: > > On Mon, 21 Mar 2005, Ignacio Vazquez-Abrams wrote: > > > > > clearlooks: An attractive GTK+ 2 engine with a focus on usability > > > > > > Clearlooks will transform your GNOME desktop into an attractive looking > > > and usable environment. > > > > > > Reviewers: Jeremy Katz, Michael Schwendt, Ralf Corsepius, Adrian Reber > > > Maintainer: Ignacio Vazquez-Abrams > > > > Is it ok to package a Gnome theme as 'clearlooks' when it > > will become the default theme in Gnome ? If so, wouldn't > > gnome-themes-clearlooks not be a better name ? Like gnome-themes and > > gnome-themes-extras already set a precedent. > > https://www.redhat.com/archives/fedora-extras-list/2005-March/msg00317.html > https://www.redhat.com/archives/fedora-extras-list/2005-March/msg00453.html > https://www.redhat.com/archives/fedora-extras-list/2005-March/msg00569.html Ok, I've only subscribed this weekend to fedora-extras. (For some reason I thought I was already subscribed to every fedora mailinglist, but I noticed today I'm still missing the buildsystem mailinglist, sigh) None of these mails seem conclusive on the subject and since I was subscribed to fedora-packaging I would have expected such a discussion/decision there probably. I think package naming is an important (and the first) part of good packaging and I would hate to see a Gnome theme be packaged like an application or library. The current guidelines already have some policy for plugins and extras, so I think this is an obvious extension to that. The same is true for Gnome (or other) applets. foo-applet could be an applet for a lot of things, so gnome-applet-foo seems a much better scheme. -- dag wieers, dag(a)wieers.com, http://dag.wieers.com/ -- [all I want is a warm bed and a kind word and unlimited power]

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

packaging March 2005