Request to drop %(%{__id_u} -n) in preferred buildroot
by Axel Thimm
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
16 years, 8 months
--vendor fedora, rationale/motivation?
by Rex Dieter
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.
16 years, 10 months
Re: atrpms kernel modules
by Axel Thimm
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
17 years, 1 month
missing this week's meetings
by Tom Callaway
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!
17 years, 1 month
COPYING (license) not under docdir
by Axel Thimm
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
17 years, 1 month
missing this week's IRC meeting(s)
by Rex Dieter
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
17 years, 1 month
PHP guidelines
by Jason L Tibbitts III
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<
17 years, 2 months
BuildRoot
by Matthias Saou
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
17 years, 2 months
Advice sought on a package currently under review
by Paul F. Johnson
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
17 years, 2 months
Extras packages violating versioning schemes
by Michael Schwendt
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}
17 years, 2 months
