perl module MODULE_COMPAT
by Warren Togami
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
17 years, 11 months
dist tag revisited
by Tom Callaway
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!
17 years, 11 months
Re: [Fedora-packaging] %{_libdir}/rpm/brp-compress for perl modules
by Alan Milligan
-----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-----
17 years, 12 months
%{_libdir}/rpm/brp-compress for perl modules
by Warren Togami
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
17 years, 12 months
questions regarding kernel-devel and kernel-smp-devel packages
by Jef Spaleta
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
17 years, 12 months
Running scriptlets only in certain situations
by Chuck Anderson
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.
18 years
Alternative kernel packages
by Orion Poplawski
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
18 years
Importing tetex packages question
by Jose Pedro Oliveira
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 *
18 years
Re: gnome-theme-clearlooks please Re: APPROVED: clearlooks
by Dag Wieers
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]
18 years
Re: APPROVED: clearlooks
by Dag Wieers
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]
18 years
