Re: Heads-up: %define vs %global in specs
On Tue, 5 Jan 2010, Panu Matilainen wrote:
For the impatient:
Starting with today's rawhide, the these kind of constructs in specs no
longer work:
%{?!foo: %define foo bar}
For the generally desired effect, the above simply becomes:
%{?!foo: %global foo bar}
This is already recommended by the Fedora guidelines, but packages which
haven't been updated to follow the guideline might need revising:
https://fedoraproject.org/wiki/Packaging/Guidelines#.25global_preferred_over_.25define
FYI, this change broke font package macros.
I've reverted the macro scoping fix until I have a chance to properly
investigate the breakage (possibly some quirk related to %{lua: ...}
macros).
- Panu -
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Question about dist-cvs make targets
On Thu, 7 Jan 2010, Jesse Keating wrote: As I proceed to port our make system over into fedpkg, I've ran across a couple targets that are giving me pause. Is anybody out there making use of the following targets? unused-patches I use this fairly often, typically to clean up leftovers after rebasing to new version. - Panu - -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Heads-up: %define vs %global in specs
For the impatient:
Starting with today's rawhide, the these kind of constructs in specs
no longer work:
%{?!foo: %define foo bar}
For the generally desired effect, the above simply becomes:
%{?!foo: %global foo bar}
This is already recommended by the Fedora guidelines, but packages which
haven't been updated to follow the guideline might need revising:
https://fedoraproject.org/wiki/Packaging/Guidelines#.25global_preferred_over_.25define
The longer version:
As explained in the guidelines, %define nested in %{ } block was never
supposed to work, but due to a longstanding bug in rpm macro engine it has
seemed to work in many cases... until you do something completely
unrelated in the spec and it suddenly breaks in mysterious ways. Consider
this example spec:
--- snip ---
%{!?foo: %define foo bar}
%define dofoo() true
Name: macroscope
Version: 1.0
Release: 1
License: Testing
Summary: Testing macro behavior
%description
%{summary}
%prep
echo 1: %{foo}
%dofoo
echo 2: %{foo}
%files
%defattr(-,root,root)
--- snip ---
You'd probably expect %{foo} to expand to bar in both 1 and 2, but due
to this funny little macro buglet, you'd get this rather non-obvious
result:
1: bar
2: %{foo}
What you start getting now is:
1: %{foo}
2: %{foo}
...in other words, the %define inside %{} block goes out of scope when the
block ends, and you probably wanted to use %global there instead.
- Panu -
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Heads-up: %define vs %global in specs
On Tue, 5 Jan 2010, Daniel P. Berrange wrote:
On Tue, Jan 05, 2010 at 06:34:12PM +0200, Panu Matilainen wrote:
For the impatient:
Starting with today's rawhide, the these kind of constructs in specs
no longer work:
%{?!foo: %define foo bar}
For the generally desired effect, the above simply becomes:
%{?!foo: %global foo bar}
This is already recommended by the Fedora guidelines, but packages which
haven't been updated to follow the guideline might need revising:
https://fedoraproject.org/wiki/Packaging/Guidelines#.25global_preferred_over_.25define
What exactly do you mean 'no longer work' ? Can we expect to get a formal
RPM build error for this bogus construct, or will it silently build and
do the wrong thing ? From your long description, it sounds like the latter,
which means maintainers should audit their spec files to identify these
bogus macros
It depends on the details but most likely you'll get a build error of some
kind as you'll get unexpanded macros where you previously got expanded
macros (if you were lucky). For example
%{!?python_sitelib: %define python_sitelib %(python -c from distutils.sysconfig
import get_python_lib; print get_python_lib())}
...
%files
%{python_sitelib}/mystuff.py
...would now error out at filelist processing stage as %{python_sitelib}
is not defined in the global scope and literal
%{python_sitelib}/mystuff.py is not a valid file name.
Or you can get downright parse errors etc. Sure there *are* cases where it
could go unnoticed: if you're creating package content based on such a
%define - using the python_sitelib again as a dumb example, rpm wouldn't
complain about file created (and packaged) from this, you'd just get wrong
contents (unexpanded macro name) in the file:
cat EOF my.conf
%{python_sitelib}/mylib/
EOF
...but the potential for such silent errors has been there all the
time: you just need to call a parametrized macro (knowingly or as a
side-effect) somewhere in the spec and poof.
Oh and btw, technically there's nothing illegal or wrong with the
construct %{?!foo: %define foo bar} itself. What's wrong is trying to
*use* macro defined that way outside the %{} block where it was defined.
- Panu -
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: ATTN: Changes to OCaml dependency generator for RPM 4.8 in Rawhide
On Wed, 16 Dec 2009, Richard W.M. Jones wrote:
Since RPM 4.8 (now in Rawhide / Fedora 13), the external dependency
generator that we used to ship with OCaml has now gone upstream into
RPM. This is a Good Thing, thanks to the RPM maintainers for adding
this.
If you own an OCaml library package, then there are some simple
adjustments you need to make to your OCaml spec files _in Rawhide_.
First of all, remove any lines that are exactly like any of these:
%define _use_internal_dependency_generator 0
%global _use_internal_dependency_generator 0
%define __find_requires /usr/lib/rpm/ocaml-find-requires.sh
%global __find_requires /usr/lib/rpm/ocaml-find-requires.sh
%define __find_provides /usr/lib/rpm/ocaml-find-provides.sh
%global __find_provides /usr/lib/rpm/ocaml-find-provides.sh
Any remaining calls to ocaml-find-{requires,provides}.sh must be ones
which take parameters, and these need to be modified.
Change:
%define __find_requires /usr/lib/rpm/ocaml-find-requires.sh params...
or:
%global __find_requires /usr/lib/rpm/ocaml-find-requires.sh params...
to:
%global __ocaml_requires %{_rpmconfigdir}/ocaml-find-requires.sh params...
Better yet, instead of overriding the __ocaml_requires (and _provides)
macros, use the new option passing mechanism. See below...
and the same for provides instead of requires.
For example, if your original spec files contained this block:
%define _use_internal_dependency_generator 0
%define __find_requires /usr/lib/rpm/ocaml-find-requires.sh -i Asttypes -i
Parsetree
%define __find_provides /usr/lib/rpm/ocaml-find-provides.sh
then following the rules above it would become:
%global __ocaml_requires %{_rpmconfigdir}/ocaml-find-requires.sh -i Asttypes
-i Parsetree
With the new rpm, all you need to have in the spec for this case is:
%global __ocaml_requires_opts -i Asttypes -i Parsetree
These will get passed to __ocaml_requires automatically when it runs,
and similarly to pass options to provides script, define
__ocaml_provides_opts macro to your liking.
Oh and this is not ocaml-specific, any of the __foo_requires /
__foo_provides helpers accept options in the same manner.
- Panu -
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: rawhide and tagging requests
On Thu, 10 Dec 2009, Seth Vidal wrote:
On Thu, 10 Dec 2009, Jesse Keating wrote:
On Thu, 2009-12-10 at 10:56 +0200, Panu Matilainen wrote:
Hmm, looking at the traceback at the end of
http://kojipkgs.fedoraproject.org/mash/rawhide-20091209/logs/mash.log it's
not at all clear whether this is rpm-python bustage or yum... the
last
good compose (from 20091203) was before this went in:
* Thu Dec 3 2009 Seth Vidal skvidal at fedoraproject.org - 3.2.25-2
- rebuild yum with latest HEAD patch
- add rpmdb caching patch james wrote to see if it breaks everyone :)
...and the rpmdb caching patch does touch the area where it's
crashing.
Can you try a compose with yum tagged down to 3.2.25-1 just to cut
down on
the moving parts involved?
Alternatively a reproducer that doesn't involve processing the entire
rawhide would be helpful :)
Yeah, it could totally be yum, I didn't do much investigation into it.
Just didn't have it in me as I'm stranded at an airport over night.
Looking at the rpmdb caching patch I'm not sure how it could be that. The
parsing of local pkgs (what createrepo does) doesn't hit the rpmdb.
Yup, but this isn't createrepo crashing (the earlier one was):
2009-12-09 20:11:04 mash: createrepo: finished
/mnt/koji/mash/rawhide-20091209/development/x86_64/os/
2009-12-09 20:11:05 mash: Resolving multilib for arch x86_64 using method
devel
2009-12-09 20:11:05 mash: Waiting for depsolve and createrepo to finish...
2009-12-09 20:21:28 mash: Resolving depenencies for arch x86_64
Traceback (most recent call last):
File /usr/bin/mash, line 96, in module
main()
File /usr/bin/mash, line 84, in main
rc = themash.doMultilib()
File /usr/lib/python2.6/site-packages/mash/__init__.py, line 538, in
doMultilib
pid = self.doDepSolveAndMultilib(arch, repocache)
File /usr/lib/python2.6/site-packages/mash/__init__.py, line 511, in
doDepSolveAndMultilib
(rc, errors) = yumbase.resolveDeps()
File /usr/lib/python2.6/site-packages/yum/depsolve.py, line 718, in
resolveDeps
for po, dep in self._checkFileRequires():
File /usr/lib/python2.6/site-packages/yum/depsolve.py, line 1012, in
_checkFileRequires
po = self.getInstalledPackageObject(pkgtup)
File /usr/lib/python2.6/site-packages/yum/__init__.py, line 2421, in
getInstalledPackageObject
raise Errors.RpmDBError, _('Package tuple %s could not be found in
rpmdb') % str(pkgtup)
yum.Errors.RpmDBError: Package tuple ('clamav-scanner-upstart', 'noarch',
'0', '0.95.3', '1301.fc13') could not be found in rpmdb
- Panu -
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
Heads-up: RPM 4.8.0-beta1 about to hit rawhide
Now that FESCo has approved new major RPM version for F-13 and the public beta is officially out... it's going to hit rawhide in a few hours. Couple of practical issues: - Soname bump is involved, so anything directly linking to librpm needs to be rebuilt. This includes deltarpm, gdb, net-snmp, abrt and a few others. - The new version has integrated support for extracting OCaml dependencies, this clashes with the existing ocaml-dependency extraction mechanism in Fedora. Notably rpm-build conflicts with current ocaml-runtime, and the ocaml build-macros need updating to let the integrated pieces do their work. And of course, watch out for regressions: From Fedora POV perhaps the biggest suspect is the python bindings as they've seen a pretty dramatic cleanup and revamp all over. It's supposed to be compatible for the commonly used parts (eg yum certainly works fine with it) but I'd be rather surprised if some rarely used dark corner hasn't broken up. Another thing to watch out for is installation (and erasure) ordering. The algorithm has been pretty much rewritten and produces significantly different orderings than the previous one. However note that different != incorrect, the old algorithm completely blew it up in various dependency loop cases etc. So if something worked with the previous versions but no longer does with the new beta, it doesn't automatically mean it's a bug in the new ordering code: you might've just been lucky. Any regressions in this area need to be carefully analyzed case by case to determine whether they're true regressions or just incorrect dependencies in packages. - Panu - -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Remove uses of %{PACKAGE_VERSION} and %{PACKAGE_RELEASE} from specs
Grepping through spec files from CVS devel/ shows there are a handful of
package still using %{PACKAGE_VERSION} and %{PACKAGE_RELEASE} macros.
These were considered backwards compatibility stuff in 1998 (yes, eleven
years ago) already, please change them to use the %{version} and
%{release} macros instead.
The packages using these ancient macros are:
- kernel
- kernel-xen-2.6 (dead package?)
- glibc32, glibc64 (dead packages?)
- fmt-ptrn
- libunwind
Rpm = 4.8.x removes the support for the ancient %{PACKAGE_*} macros so
packages still using them will fail to build with it.
- Panu -
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
Looking for testers: RPM 4.8 pre-release snapshots available
It's that time of year again... we're planning on getting a brand new RPM version into Fedora 13. While the feature submission is being processed and public beta being prepared, we'd like to get some extra testing of the new RPM to catch out any remaining wrinkles our own testing hasn't caught. So this is a call for brave testers who eat rawhide for breakfast, to try out pre-release snapshot(s) of the oncoming RPM release. This is not supposed to eat your system alive or anything - I've used snapshots from rpm.org HEAD on my systems througout the development process without problems but you never know... so proceed with appropriate caution. For an idea what to expect, see the draft release notes at http://rpm.org/wiki/Releases/4.8.0 You can find Fedora compatible snapshots of the day source rpms from http://laiskiainen.org/rpm/srpms/ (use the latest you can find). These should be buildable on and compatible with F11, 12 and rawhide. Please report any oddities found, preferably to rpm.org Trac at http://rpm.org/newticket but mail will do too. - Panu - -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Looking for testers: RPM 4.8 pre-release snapshots available
On Fri, 27 Nov 2009, Matthew Miller wrote: On Fri, Nov 27, 2009 at 11:11:37AM -0500, Matthew Miller wrote: So this is a call for brave testers who eat rawhide for breakfast, to try out pre-release snapshot(s) of the oncoming RPM release. This is not I'm in. :) file /usr/lib/rpm/ocaml-find-provides.sh from install of rpm-build-4.7.90-0.git9625.lorg.x86_64 conflicts with file from package ocaml-runtime-3.11.1-6.fc13.x86_64 file /usr/lib/rpm/ocaml-find-requires.sh from install of rpm-build-4.7.90-0.git9625.lorg.x86_64 conflicts with file from package ocaml-runtime-3.11.1-6.fc13.x86_64 Yup, sorry I forgot to mention this: as the OCaml dependency generation has gotten integrated into rpm now, it conflicts with current ocaml-runtime. Obviously the scripts can't be removed from ocaml-runtime until the new rpm is in rawhide, but removing them from rpm isn't good either as you couldn't test the new thing... So for now: a) if you dont need it, remove ocaml-runtime b) if you do, install with --replacefiles - Panu - -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: RPM dependency on cron
On Fri, 6 Nov 2009, Benny Amorsen wrote: We have a lot of virtualized (OpenVZ) Fedora servers. Until now I have avoided running cron inside each server; log rotation is done from the host. This has worked rather well until lately. Unfortunately rpm has acquired a dependency on crontabs, because it adds a file to /etc/cron.daily. In turn, crontabs depends on /etc/cron.d, which is provided by cronie. cronie explicitly depends on anacron. And thus, anacron and cronie are required for all Fedora installations. The really nasty thing is that cronie turns itself on when installed! I suddenly had an extra logrotate running which rotated logs in a way not consistent with our policy. I'm not sure where it's easiest to cut this chain. I'd be tempted to make crontabs provide /etc/cron.d and make cronie depend on crontabs. That way rpm would pull in crontabs but nothing more. In Fedra = 12 the cronjob was split to a separate subpackage to avoid this dependency chain on minimal installs: https://bugzilla.redhat.com/show_bug.cgi?id=500722 Doing that as F11 update is not really an option though. - Panu - -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Eternal 'good file hashes' list
On Tue, 20 Oct 2009, Ralf Ertzinger wrote:
Hi.
On Tue, 20 Oct 2009 10:20:17 +0200, Tomas Mraz wrote:
What would this be good for?
To expand on the motivation for this:
The idea is to have a list of known good file hashes to test your local
files against, if you have reason not to trust your local RPM database
(which may have been compromised as well). The way I'd do that right now
would involve getting the corrensponding RPM files from a mirror (hoping
there still is a mirror for that) and then... well, then it gets a bit
fuzzy as I don't know how to check the checksum of a file against the
metadata in a RPM file but I'm sure it can be done somehow.
So I thought that there may be an easier way to do this, so I'm asking,
in a first step, for an estimate of the data size we're talking about,
as I have no idea how much metadata each file in an RPM takes up, how
many RPMs/files koji builds each day on average and so on.
Well, for example the file hashes (which are simply arrays of
hex-strings in headers) of the 2871 packages on Fedora-11-x86_64-DVD.iso:
[pmati...@localhost Packages]$ rpm -qap --qf [%{filedigests}\n] *.rpm |wc
430716 373388 24141084
To make any use of that data you'll obviously need the file names too, so:
[pmati...@localhost Packages]$ rpm -qap --qf [%{filedigests} %{filenames}\n]
*.rpm |wc
430716 804104 47467960
...but rpm stores paths indexed by directory, storing flat paths as
returned by %{filenames} wastes tonnes of space. Also note that
directories and symlinks dont have associated hashes. And of course
there's a whole lot more metadata that you need to take into account when
verifying: user+group, permissions, symlink targets etc.
- Panu -
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Howto handle multilib conflict?
On Sat, 10 Oct 2009, Christoph Wickert wrote: Am Freitag, den 09.10.2009, 18:56 -0400 schrieb Neal Becker: Just received: https://bugzilla.redhat.com/show_bug.cgi?id=528237 yum install libotf-devel.i586 libotf-devel.x86_64 yields: Transaction Check Error: file /usr/bin/libotf-config from install of libotf-devel-0.9.8-2.fc11.i586 conflicts with file from package libotf-devel-0.9.8-2.fc11.x86_64 file /usr/share/doc/libotf-devel-0.9.8/example/Makefile from install of libotf-devel-0.9.8-2.fc11.i586 conflicts with file from package libotf-devel-0.9.8-2.fc11.x86_64 What is the recommended way to resolve this? If the contents of the file is the same and they only their timestamps differ, you can touch them reversely after install as in http://cvs.fedoraproject.org/viewvc/rpms/exo/devel/exo.spec?r1=1.38r2=1.39 Timestamp differences do NOT cause file conflicts. Content (and permission) differences do. - Panu - -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Bug reporting URL field in packages
On Tue, 6 Oct 2009, Jon Masters wrote:
On Tue, 2009-10-06 at 10:43 -0700, Jesse Keating wrote:
So I guess the real question is do we want our packages built in koji to
assume a bug URL of fedora, even when used in downstream projects?
I think that's a giant assumption - if the maintainer didn't put that
URL in the package themselves, what makes you think automatically
putting it in there is going to achieve anything different? ;)
I advocate letting people choose for themselves.
Well, there's no semantics attached to the bugurl tag so it's up to distro
policies what to use it for: distro bugtracker or upstream bugtracker for
that package.
One option that would allow remapping the bug address to whatever
local configuration says would be leaving part of the bugurl tag as an
unexpanded macro, so our buildsys would define bugurl like this:
%bugurl %%{_bugurl_os}/%{name}
With that, the %{name} part is expanded at build time to effectively the
source rpm name, and the rest is up to query-time expansion. The extension
could return empty if the macro expansion fails (ie when _bugurl_os isn't
defined). Something like fedora-release could provide the %_bugurl_os
definition by default, and downstream distros, IT admins etc could
override it to whatever appropriate. It also permits controlling the
bugurl for packages from different sources like 3rd party repositories.
And changing the bug tracker base address doesn't require mass-rebuild.
That's trivial to implement, but would that be sufficient to cover the
concerns over arbitrary downstream distros pointing to Fedora bugtracker
etc, or should I just let it be?
- Panu -
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Bug reporting URL field in packages
On Thu, 8 Oct 2009, Jesse Keating wrote:
On Thu, 2009-10-08 at 11:29 +0300, Panu Matilainen wrote:
With that, the %{name} part is expanded at build time to effectively the
source rpm name, and the rest is up to query-time expansion. The extension
could return empty if the macro expansion fails (ie when _bugurl_os isn't
defined). Something like fedora-release could provide the %_bugurl_os
definition by default, and downstream distros, IT admins etc could
override it to whatever appropriate. It also permits controlling the
bugurl for packages from different sources like 3rd party repositories.
And changing the bug tracker base address doesn't require mass-rebuild.
That's trivial to implement, but would that be sufficient to cover the
concerns over arbitrary downstream distros pointing to Fedora bugtracker
etc, or should I just let it be?
Hrm, how does it help for 3rd party packages? They would hardcode the
entire string into their rpms?
They could hardcode the entire string or use their own macro for it, like
%{_bugurl_myrepo} and provide a macro in their -release package that
provides the macro definition.
- Panu -
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
Bug reporting URL field in packages
A while ago there was a request to add a bug reporting URL to packages:
https://bugzilla.redhat.com/show_bug.cgi?id=512774
This was added to Fedora's rpm recently, what's still missing is the
default contents of the %{bugurl} macro in redhat-rpm-config.
Opinions wanted:
a) just make it https://bugzilla.redhat.com
b) use http://bugz.fedoraproject.org/%{name}
c) something else, what?
- Panu -
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Bug reporting URL field in packages
On Tue, 6 Oct 2009, Juha Tuomala wrote:
On Tuesday 06 October 2009 15:48:32 Panu Matilainen wrote:
This was added to Fedora's rpm recently, what's still missing is the
default contents of the %{bugurl} macro in redhat-rpm-config.
Opinions wanted:
a) just make it https://bugzilla.redhat.com
b) use http://bugz.fedoraproject.org/%{name}
c) something else, what?
d) use host part from rpm-config, and rest from package metadata.
and then one would be able to change report database
by modifying only one package.
Something like:
rpm-config %{bugreporthost} = http://bugzilla.redhat.com/
package%{name} = bacula
-- %{bugreporthost}/%{name}
-- http://bugzilla.redhat.com/bacula
Then downstream distros and IT-organizations could try to catch
all reports to their own bug reporting systems before disturbing
Fedora - as in many cases downstream may actually be the culprit
for the problem after all.
If that would not be possible, it would force them to rebuild
all packages and burn rainforests while doing so or just
waste Fedoraproject's hours for issues that doesn't belong there.
This probably isn't something that cannot be fixed later, but
while it's on plate? ;-)
Something like that is quite easily doable by adding a RPMTAG_BUGURL tag
extension which grabs its value from macro configuration if set, otherwise
use the contents from the package.
It is out of scope for this discussion though, the question here is about
the default value Fedora packages should have. The BUGURL tag contents is
just a plain old string which is expanded from %bugurl macro at build time
and currently no further processing is done on it.
- Panu -
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Bug reporting URL field in packages
On Tue, 6 Oct 2009, Jesse Keating wrote: On Tue, 2009-10-06 at 17:37 +0300, Panu Matilainen wrote: Something like that is quite easily doable by adding a RPMTAG_BUGURL tag extension which grabs its value from macro configuration if set, otherwise use the contents from the package. It is out of scope for this discussion though, the question here is about the default value Fedora packages should have. The BUGURL tag contents is just a plain old string which is expanded from %bugurl macro at build time and currently no further processing is done on it. I think what we would like to avoid is hardcoding it in the binary rpm. One of the goals of Fedora is to have our rpms used as is in downstream respins, where it would be inappropriate for the rpm to define our bugzilla as the bug filing location. But if I get what you're saying right, you could have it hardcoded in the rpm for a case where it isn't defined (at least in part) in a macro file on the users's system, and when there is a macro file that defines it on the users's system, use that definition instead of the one in the rpm itself. Is that what you're saying? More or less, but note that an rpm level configurable override would be system global for all packages. When you enter 3rd party repositories into the picture such a scheme wont work at all, except if capturing everything is what what you want (eg some corporate IT department might want just that). We'd also want to avoid a flag day of mass rebuilding any time we want to change the landing point for people to query/file bugs for a package. Well in that case rpm is the wrong place entirely, and ditto for respins controlling their own bug report URLs. For these you'd want the bug reporting URL in repodata instead: spins are creating their own repositories so they can set it there, and regenerating the repodata to include a new url is cheaper than rebuilding all the packages. - Panu - -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: rpm/mock: can't upbuild FC10 targets on FC9 host
On Thu, 3 Sep 2009, Philip Prindeville wrote: No joy: [r...@builder SRPMS]# rm -rf /var/lib/mock/fedora-10-x86_64/root [r...@builder SRPMS]# mock -r fedora-10-x86_64 --init --rebuild perl-Net-Patricia-1.15_01-1.fc9.src.rpm Don't run mock as root. That'll avoid the incompatible db environment from getting created. Also some older versions of mock left the db environment in the root-cache tarball which is sure to cause problems sooner or later (this has been fixed since then but don't remember which version) - Panu - -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Conditionally applying a patch based on a program's EVR
On Thu, 9 Jul 2009, Alan Dunn wrote:
I want to conditionally apply a patch in a spec file based upon the
version of a package. (There's an emacs package that needs a patch to
work with the latest version of xemacs, but this patch shouldn't be
applied for previous versions of xemacs.) I know that for checking
something like Fedora version numbers I can use
%if 0%{?fedora} 9
...
%endif
but is there an easy way to do this for a version number in say, EVR
form? That is, something like
%if %{program_version} 1.2.3
...
%endif
(%{program_version} will always be defined)
RPM doesn't seem to support a mechanism like this in %if conditionals
(I believe having a digit first causes rpmbuild to try and interpret
the result as a number), though clearly there is a mechanism for
examining EVRs of this form for other parts of rpmbuild.
One could try something like
%if %{prorgram_version} 1.2.3
which does string comparison, but this doesn't work for some version
combinations, since, for example, we would want 1.10.1 1.9.1
In rpm = 4.7.0 the real rpm version comparison algorithm is available to
the embedded Lua interpreter as rpm.vercmp(), eg:
[pmati...@localhost ~]$ rpm --eval %{lua:print(rpm.vercmp('1.2.3-1',
'1.1.1-1'))}
1
[pmati...@localhost ~]$ rpm --eval %{lua:print(rpm.vercmp('1.2.3-1',
'5:1.1.1-1'))}
-1
With older rpm versions you need to do something else, such as call
rpmdev-vercmp.
- Panu -
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: [JANITOR] Duplicate directory ownership cleanups
On Fri, 26 Jun 2009, Chris Weyl wrote:
On Fri, Jun 26, 2009 at 11:48 AM, Chris Weyl cw...@alumni.drew.edu wrote:
On Fri, Jun 26, 2009 at 9:29 AM, Jussi Lehtola
jussileht...@fedoraproject.org wrote:
On Fri, 2009-06-26 at 18:07 +0200, Iain Arnell wrote:
okay, not actually broken, but this is definitely
messing with (some
of the) perl structure (and
perl-DBIx-Class-EncodedColumn already
requires perl-DbIx-Class). What gives?
diff -u -p -r1.1 -r1.2
--- perl-DBIx-Class-EncodedColumn.spec 10 May 2009 06:54:10
- 1.1
+++ perl-DBIx-Class-EncodedColumn.spec 26 Jun 2009 09:12:21
- 1.2
@@ -1,6 +1,6 @@
Name: perl-DBIx-Class-EncodedColumn
Version: 0.2
-Release: 1%{?dist}
+Release: 2%{?dist}
Summary: Automatically encode columns
License: GPL+ or Artistic
Group: Development/Libraries
@@ -55,10 +55,13 @@ rm -rf $RPM_BUILD_ROOT
%files
%defattr(-,root,root,-)
%doc Changes README
-%{perl_vendorlib}/*
+%{perl_vendorlib}/DBIx/Class/*
%{_mandir}/man3/*
This was clearly a duplicate ownership issue which spot dealt
with
correctly. perl-DBIx-Class already owns
%{perl_vendorlib}/DBIx/Class/
and thus there is no need for perl-DBIx-Class-EncodedColumn to
own the
directory since it requires perl-DBIx-Class (which owns the
directory).
Ian and Ralf are absolutely correct here. perl-* packages have for
years operated under the convention and explicit guideline that
anything we deliver under %{perl_vendorlib} or %{perl_vendorarch} must
be owned by the package providing it.
The canonical example here generally involves differing vendorarch/lib
dirs, as they're versioned by Perl. E.g. if perl-DBIx-Class was built
under 5.10.0, it's going to put its bits under
/usr/lib/perl5/vendor_perl/5.10.0. In the meantime if we go to Perl
5.10.1 and build perl-DBIx-Class-EncodedColumn under that level, it
will use /usr/lib/perl5/vendor_perl/5.10.1 as its directory... leaving
/usr/lib/perl5/vendor_perl/5.10.0/DBIx/Class/ unowned.
...or, if XS (arch-specific) bits were added to perl-DBIx-Class (which isn't
terribly unlikely), all of a sudden it would be using directories under
/usr/lib64/perl5/vendor_perl/5.10.0/x86_64-linux-thread-multi, not
/usr/lib/perl5/vendor_perl/5.10.0... Also hosing directory ownership.
(noarch/arch changes like this are rare, but hardly uncommon.)
Another, perhaps clearer way of saying this is:
perl-DBIx-Class-EncodedColumn will require perl-DBIx-Class through the
virtual perl provide of perl(DBIx::Class); yet requiring perl(DBIx::Class)
does not guarantee that any particular directory under Perl lib paths (@INC)
will be created and owned.
Perl requires are managed through the perl(*) set of virtual provides.
Depending on a certain perl(*) provide to own specific directories is risky
at best, and a mess towards its worst. The only sane, clean and consistent
way to deal with this is for each perl-* package to own everything it
provides.
Other than what a mess :) ... yes this is fine and harmless from rpm
POV. It's the entirely silly cases like these (just a random sampling
from the big big list to make the point hopefully clear) I'd like to see
weeded out:
multiprovided dir /usr/share/man/man1
- filesystem-2.4.21-1.fc11.x86_64
- gnome-power-manager-2.26.1-3.fc11.x86_64
- policycoreutils-2.0.62-12.6.fc11.x86_64
multiprovided dir /usr/share/man/man8
- filesystem-2.4.21-1.fc11.x86_64
- policycoreutils-2.0.62-12.6.fc11.x86_64
- selinux-policy-3.6.12-39.fc11.noarch
multiprovided dir /usr/share/applications
- filesystem-2.4.21-1.fc11.x86_64
- system-config-httpd-5:1.4.4-4.fc11.noarch
- xsane-0.996-7.fc11.x86_64
multiprovided dir /usr/share/locale/es/LC_MESSAGES
- avahi-0.6.25-1.fc11.x86_64
- filesystem-2.4.21-1.fc11.x86_64
- glibc-common-2.10.1-2.x86_64
- kde-i18n-Spanish-1:3.5.10-4.fc11.noarch
- kde-l10n-Spanish-4.2.2-1.fc11.noarch
Practically all packages will end up having a relation to filesystem
anyway, so most likely no information lost if the cases like above are
simply ignored. But consider this:
multiprovided dir /usr/lib64/pkgconfig
- freetype-devel-2.3.9-3.fc11.x86_64
- libXScrnSaver-devel-1.1.3-2.fc11.x86_64
- pkgconfig-1:0.23-8.fc11.x86_64
Quite clearly pkgconfig should be the only owner of that directory, and
this is a lost opportunity to automatically do the right thing in ordering
based on just the directory information.
- Panu -
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: update mechanism for new releases
On Tue, 23 Jun 2009, Martin Langhoff wrote: On Tue, Jun 23, 2009 at 9:10 PM, Mathieu Bridon (bochecha)boche...@fedoraproject.org wrote: RPM has seen a lot of improvements in speed and memory consumption Are there any improvements on recovery of unexpectedly failed transactions, such as OOM, kernel oops or hard power-off? Other than thinking about it, and trying hard to get memory usage during transaction to bare minimum to avoid the OOM's in the first place, no. According to valgrind/massif, rpm 4.7.x heap consumption during the transaction execution is mere megabytes (+ size of a single header at a time) even for largish transactions. We throw away pretty much everything that can be reconstructed at the time of actual package install stage when the full header is (re)loaded, whereas older versions kept the entire file info sets (by far the biggest memory consumer) of all packages loaded throughout the transaction. There's still work left in the memory use area though: now with the heap consumption down we need to figure out what's keeping RSS much higher than it should optimally be and what can be done about it to see the full benefit of the internal memory savings. Restarting an interrupted transaction is an interesting (and hard) problem. There's quite a pile of state that needs recording to persistent store and teaching various parts of the transaction machinery to use that, and questions like what to do if we can't get the same exact packages at replay time, short of having rpm make hardlinks (or copies if hardlink is not possible) - rpm itself knows nothing about where a package came from, packages can vanish from repositories etc... - Panu - -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: [JANITOR] Duplicate directory ownership cleanups
On Fri, 26 Jun 2009, Michael Schwendt wrote: On Fri, 26 Jun 2009 06:30:01 -0400, Stephen wrote: I think he's just talking about clearing up unnecessary duplication (like with his php-pear example) that confuses the yum dependency checker. Hmmm? Tom's announcement doesn't mention any such confusion. Are there really dependencies on directories being used which cause the depsolver to pull in a wrong package? Dependencies on paths outside /etc and *bin* ought to be the exception, not the rule. In particular, since they require the optional filelists metadata to be downloaded and parsed. I've recently cleaned up some wrong ownership of %_libdir/pkgconfig/, but in general I think Tom should rather help with fixing unowned directories and implicit conflicts instead. ;) This is not so much about yum, but about possibly enabling rpm to use the directory hierarchy for additional hints in transaction ordering (and general sanity, ownership of eg translation-related directories is a huge mess without a good reason): https://www.redhat.com/archives/fedora-packaging/2009-June/msg00059.html There are several complications that need to be resolved somehow before it's possible in practise though. - Panu - -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: rpms/polkit-gnome/devel polkit-gnome.spec, NONE, 1.1 .cvsignore, 1.1, 1.2 sources, 1.1, 1.2
On Tue, 9 Jun 2009, Matthias Clasen wrote: On Tue, 2009-06-09 at 14:58 +0200, Christoph Wickert wrote: # for /usr/share/gnome/autostart Requires: gnome-session Great! This adds gnome-session: 1.8 MB control-center: 7.1 MB GConf2: 5,5 MB gnome-keyring: 2,3 MB gnome-vfs2: 3.1 MB You added at least ~ 22,8 MB overhead just for directory ownership, although I asked you to _not_ do this. I think users of alternative desktops and the maintainers of their spins will not be amused. Last week you told me, that a one advantage of the new polkit is that no longer requires GConf2, but now it's dragged in again. Your anger is misdirected. Complain to the rpm people for not handling directories in a sane way. Or better still, send them a patch... Define sane. The unowned directory issue was hashed at quite a length in January [1], every option was disliked by somebody. Short summary of the options discussed: a) Create file dependencies for every directory not explicitly owned by the package at build time. Easy to do and works with everything out there but causes *huge* metadata bloat. b) Calculate directory dependencies at runtime. Easy to do but either causes transactions to abort due to missing dependencies whenever unowned directories are found, or would require changing all the depsolvers to know about and handle the implicit directory dependencies too. c) Have rpm silently add ownership of unowned directories to the package that creates them. This could cause weird directory conflicts when some other package actually owns the directory / becomes the owner, and just feels wrong anyhow. d) Variations of a-c where it'd just warn about the unowned directories. I've been playing with using directories for additional ordering information (fairly easy to do), c) is basically a one-liner patch on top of that. [1] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg02326.html - Panu - -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: File Triggers (was Re: Proposal (and yes, I'm willing to do stuff!): Must Use More Macros)
On Wed, 10 Jun 2009, Nicolas Mailhot wrote:
Le Mer 10 juin 2009 10:59, Florian Festi a écrit :
Nicolas Mailhot wrote:
1. something auto-triggered transparently (didn't we learn anything
from
existing package triggers?).
I think you make the wrong comparison here (although I admit that the
matching names make it tempting). Triggers fill holes in the scriptlet
mechanism and though are restricted to obscure and complicated cases.
The new trigger proposal has exactly the same problem as existing
triggers: processing which is specified in a separate package, and
happens magically if this package is available (on system or on build
root), without the packager of the current package having any control
on it. It will lead to exactly the same weird bugs and packager pain.
Again, if you think you've factored out some cool processing function,
please oh please give it a proper name/id and convince packagers to
explicitely invoke this name/id in their specs do not inject code
behind their backs.
Wishing it all to happen transparently with no packager action is
laudable, but in practice all past attempts to do so have ended up in
pain for packagers and as they say the road to hell is paved with good
intentions
File triggers are certainly not the holy grail of packaging, they're only
applicaple to a pretty limited set of situations, from the top of my head:
1) Caches updaters which you only want to run once per transaction:
- ldconfig
- scrolkeeper-update
- gtk-update-icon-cache
- update-desktop-database
- fc-cache
2) Files in well-known locations that might be automatically registerable:
- install-info add + remove of %{_infodir}/*.info*
- init scripts (chkconfig --add/--del, service stop/condrestart)
- gconf schema install+remove
- plugin registrations
The cases in 1) are the classic file trigger examples, things that
aren't absolutely critical for the package itself to be runnable, and
where false positives / multiple unnecessary runs are not dangerous at
all. They're just telling some other package please update your caches.
I dont see any point in requiring special extra magic in specs to activate
them.
The cases in 2) differ in varying degrees. Info-file
registration/unregistration seems safe enough to me: by putting an *.info*
file into %{_infodir} you are announcing it's an info file. There's not
much room for mistakes here I'd think, and it's quite close to category 1)
actually, except it needs to run at different times (to handle removal).
Services and gconf .. might not be so obvious, and whether plugin
registration/unregistration can reliably be done automatically is
case by case.
In both categories there's a big difference to the current name/provide
triggers: with file triggers you knowingly place something into some other
packages directory, so following the principles of directory ownership you
should already depend on the other package. With name/provide triggers any
completely unrelated package can do anything at all at any time. Maybe
packages should only be able to add triggers on directories they actually
own (subject to abuse too but then what isnt...).
AFAICT, you're talking what would basically be a named trigger, to which
packages subscribe to if they want to. It's not at odds with file
triggers at all, and both are likely to get implemented sooner or later.
What distros choose to use for particular task is up to their packaging
committees and whatnot, rpm is to only provide a mechanism, not policy
or any magic internal triggers here.
- Panu -
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: File Triggers (was Re: Proposal (and yes, I'm willing to do stuff!): Must Use More Macros)
On Wed, 10 Jun 2009, Nicolas Mailhot wrote:
Le Mer 10 juin 2009 13:21, Panu Matilainen a écrit :
File triggers are certainly not the holy grail of packaging, they're
only
applicaple to a pretty limited set of situations, from the top of my
head:
1) Caches updaters which you only want to run once per transaction:
- ldconfig
- scrolkeeper-update
- gtk-update-icon-cache
- update-desktop-database
- fc-cache
Actually, I doubt we will ever run fc-cache once per transaction. The
consequences of bad fontconfig caches are just too high. What we've
been doing is runing fc-cache just-as-needed by making each srpm
install files in a different directory and having resulting rpms
refresh only this directory cache, instead of processing all the
system font directories each time a font package is installed.
Well, I'm not intimately aware of the font handling details nor do I
want to be, I was just under the impression the font cache belongs to the
category 1). And this is why the actual script to do whatever magic it
needs to do, when it needs to, would be in a distros fontconfig package,
not rpm.
2) Files in well-known locations that might be automatically
registerable:
- install-info add + remove of %{_infodir}/*.info*
- init scripts (chkconfig --add/--del, service stop/condrestart)
- gconf schema install+remove
- plugin registrations
The cases in 1) are the classic file trigger examples, things that
aren't absolutely critical for the package itself to be runnable, and
where false positives / multiple unnecessary runs are not dangerous at
all.
Multiple runs yes, false positives do not be so sure. False positives
is the main weakness of this proposal and good stuff will happen if
the autoselection is correct is very different from bad stuff won't
happen if the autoselection is false.
False positive in this context would mean either
a) the cache update run without needing to
b) a package put something into a wrong directory
a) is harmless as per multiple runs, b) is a grave packaging bug which
with file triggers would be caught when installing the buggy package,
instead of next cache update started by something else which then might
blow up/issue warnings long time afterwards.
They're just telling some other package please update your
caches.
And relying on the cache updating utilities to have ironclad false
positive protection logic. Which is not a given, since those utilities
have always been explicitely invoked with a human sanity-checking
input files before.
See above, they already need an ironclad false positive protection.
BTW: the system can usually manage when those caches are stale, not
when they are corrupted.
I dont see any point in requiring special extra magic in specs to
activate
them.
The cases in 2) differ in varying degrees. Info-file
registration/unregistration seems safe enough to me: by putting an
*.info*
file into %{_infodir} you are announcing it's an info file. There's
not
much room for mistakes here I'd think, and it's quite close to
category 1)
actually, except it needs to run at different times (to handle
removal).
This is backwards IMHO
1. it relies on all interesting files having a clear FHS location or
unambiguous file name
The idea of file triggers is *based* on the well known locations. If
something doesn't have a clear and well known location, file triggers are
not at all the right solution for it.
2. it relies on the packager guessing the right places to put his
files to trigger processing. The logic should not be I have an info
file, let's put it here so rpm guesses it's an info file and does the
right thing.
There's hardly guessing involved, you put things where they belong just
like you're currently doing: the canonical location for info files is
%{_infodir} and not %{_libdir}/mypackage/ for example, and the info
trigger would not look anywhere outside %{_infodir}. So for the average
autoconf using software it's taken care of by %configure already.
Again, if something doesn't have a well defined place, file triggers
shouldn't be used.
The logic should be I tell rpm this is an info file and
rpm does the right thing, including installing it in the right place.
That forces *rpm* to know something about any arbitrary file type and
location you might ever want to handle. You know how well that works for
automatic dependency generation - I really doubt you want more of the
same. The knowledge belongs to the packages knowing how to handle
something, be it fontconfig or icon cache or whatever.
This is of course the POW of a packager that has to cope with
imperfect tools that try to be smarter than they can be, not the POW
of the person that writes the smart tools and is convinced he can't do
wrong.
See above, this is why you dont want *rpm* in control of things, only to
provide a mechanism to utilize where it makes sense.
Now, some way to register build-time trigger warnings your package is
installing X file that seems
Re: rpms/polkit-gnome/devel polkit-gnome.spec, NONE, 1.1 .cvsignore, 1.1, 1.2 sources, 1.1, 1.2
On Wed, 10 Jun 2009, Nicolas Mailhot wrote: Le Mer 10 juin 2009 15:28, Matthias Clasen a écrit : I think we want something slighly less than this; rpm should track the fact that a directory was created just because some files needed to be put there, and it should be able to clean up if the last such file is removed. But I should not fully assign ownership of the directory to the packages that just drop files in there. Ref-counting of implicitly owned directories of some sort. That assumes all directory permissions are created equal, which isn't the case. Explicit automatic rpm directory ownership (à la rpm5.org, with the associated metadata growth), AFAIK rpm5.org generates the directory dependencies at runtime from data already present in headers, ie the case b) I described here: https://www.redhat.com/archives/fedora-devel-list/2009-June/msg00671.html. There's no associated metadata growth with that option, it's easy to add and forces directory ownership to be sorted out in the packages, otherwise the packages are simply uninstallable. The directory information is of course in repodata too, but in the costly filelists part. Smart and apt have to download it anyway so they could be taught to look at directories with little zero extra cost, yum is the one that would take an extra hit here by having to always download filelists unlike now. Or move the directories into the primary metadata piece, or do a second depsolve + download round after ts.check() to pull in the runtime dependencies. In any case, every depsolver needs some modifications to work smoothly with this option. - Panu - -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: File Triggers (was Re: Proposal (and yes, I'm willing to do stuff!): Must Use More Macros)
On Fri, 5 Jun 2009, Ray Strode wrote:
Hi,
On Fri, Jun 5, 2009 at 2:05 PM, Adam Williamsonawill...@redhat.com wrote:
On Fri, 2009-06-05 at 13:50 -0400, Ray Strode wrote:
It seems to me it'd make sense to convert all these kinds of snippets
into macros. Am I right, or is there a reason against doing this?
It would be awesome to get rid of the boilerplate. Honestly though,
I'd rather the solution was just works than replace giant glob of
muck with %{glob_of_muck}
Yes indeed, this would be best in many cases. Some can't really be done
like that, though - like the snippets for Tcl and Python to define the
version, directories for certain types of file and so on. They're
just...informational. Defining them as macros seems the optimal
solution.
Right, totally agree.
Yes, having each and every spec carry the %{!?foo:¤%¤%} macro goo makes
no sense at all.
For instance, if a file gets dropped under /usr/share/icons/something
rpm should run gtk-update-icon-cache /usr/share/icons/something
automatically.
the gtk2 package should be able to drop a file in /usr/lib/rpm/redhat
that makes that happen. likewise, desktop-file-utils should be able
to drop a file there to make update-desktop-database get run and so
on.
I don't know how hard it would be to fix rpm to allow for that though.
The hardest part is getting the design right the first time, there's no
changing an api that is exposed to packages.
This is definitely possible; Mandriva (I know I talk about MDV a lot,
I'm sorry, it's what I know! :) does this, via an implementation called
'file triggers'. This is not yet upstream, though.
The MDV patch that implements this is:
http://svn.mandriva.com/cgi-bin/viewvc.cgi/packages/cooker/rpm/current/SOURCES/rpm-4.6.0-rc1-filetriggers.patch?view=markup
MDV's wiki discussion of it is here:
http://wiki.mandriva.com/en/Rpm_filetriggers
It appears to be something upstream has thought about several times.
Here's an RPM 5 community discussion of it, with Jeff Johnson's
thoughts:
http://rpm5.org/community/rpm-devel/2959.html
Here's a discussion from the rpm.org Wiki:
http://www.rpm.org/wiki/Problems/Scriptlets
Oh neat!
I'm not sure what the current status is for rpm.org - whether they're
actively working on a solution for this side of things or what.
Panu, does this patch make sense?
I'm quite well aware of the Mandriva filetriggers patch, but I (too) have
some reservations about the implementation. Other issues aside,
constraining file triggers to stuff that runs after the transaction
completed limits the possibilities a lot. Many things need unregistering
(services, gconf schemas, info files...) and that needs to happen *before*
the files got removed. That's not possible in post-transaction stage.
I've been playing with a different approach: putting an existing (since
rpm 4.4.0 IIRC) but completely unused hook mechanism into use, this
allows pushing pretty much the entire mechanism out of rpm proper and into
Lua, which allows for far more flexibility for distros to customize etc.
The most simple variant consists of a whopping two-line patch to rpm:
http://laiskiainen.org/tmp/rpmhook-example/
This works by comparing modification times of directories of interest -
not sufficient for a real-world implementation but still works quite well
(and with essentially zero overhead) for the update some cache on demand
class of cases, as false positives dont generally matter there.
Things like automatically registering and unregistering info/gconf etc
files need more information than just directory changed. What they need
is access to package file lists and the file fate information (such as
these files are about to be removed), and the ability to run the
triggers at start/in middle of transaction. Mostly a matter of planting
some extra hooks into strategic spots, and extending the rpm-lua
interface.
One of the nice things about the hook-based approach is that it permits
each trigger to use whatever mechanism is best suited for the job:
processing file names/globs and remembering matches can be quite
expensive, so a trigger that doesn't need the details can just use a
simple directory modification time based approach.
Also for ultimate power the file triggers need to be in headers so that
all triggers are ready for action before the transaction starts, to avoid
unnecessary dependencies and ordering issues. And then you'll need
semantics for upgrade of a package containing file triggers - you probably
dont want the trigger from both the already installed package and the
upgraded package to run.
It's a fair-sized puzzle to get all the bits sufficiently right the first
time, or alternatively expose things little by little in a manner that
doesn't paint us in a corner.
- Panu -
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Removing %clean (Was Re: Agenda for the 2009-05-26 Packaging Committee meeting)
On Tue, 26 May 2009, Tom \spot\ Callaway wrote:
On 05/26/2009 04:10 AM, Richard W.M. Jones wrote:
I vote for also removing the %clean section.
So, looking at this objectively, here are the technical problems:
* We're defining a BuildRoot in the spec, but that definition is no
longer used (Fedora 10 or higher), because rpm now automagically sets it
for us.
* We're typing rm -rf %{buildroot} multiple times in every single Fedora
specfile. We want to invoke it twice:
- As the very first operation of the %install scriptlet
- As the very first operation of the %clean scriptlet
The concerns around removing the BuildRoot from the spec is that if that
spec is taken to an older system, the spec would either
* Not work
* Set the BuildRoot to / and cause massive system destruction
The good news is that for all the Fedora targets that we care about, if
BuildRoot is unset, it is just unset. It never gets set to / on anything
we care about (including RHEL 4 and 5, I checked).
And I really don't think we need to care about anything older than RHEL
4 (roughly equivalent to Fedora 6). A comment in the packaging
guidelines should be sufficient, so simply dropping the unnecessary
BuildRoot definition as soon as Fedora 9 is EOL seems like a sane course
of action.
The %install scriptlet case is reasonably simple to solve with
redhat-rpm-config's customized macros file, simply add:
%__spec_install_pre %{___build_pre}\
[ $RPM_BUILD_ROOT != / ] rm -rf ${RPM_BUILD_ROOT}\
mkdir -p `dirname $RPM_BUILD_ROOT`\
mkdir $RPM_BUILD_ROOT\
%{nil}
This ensures that every time %install is invoked in a spec file, it
checks that buildroot isn't / (which, it should never ever be, but given
the past history, doesn't hurt to check), then deletes it. Next, it
makes the basedir of $RPM_BUILD_ROOT, in case that doesn't exist, then
makes the buildroot for us, saving additional pain in some Fedora spec
files where the make install process is either too dumb to do this for
us (or non-existant).
Yup, %install part is mostly a no-brainer. While at it...
redhat-rpm-config redefines %install, %build and some others as macros
which has some strange/unwanted side-effects. Switching these to use
templates instead wouldn't hurt.
The %clean scriptlet case is harder. Lets get the easy case out of the
way, removing the obligatory rm -rf %{buildroot} invocation:
%__spec_clean_pre %{___build_pre}\
[ $RPM_BUILD_ROOT != / ] rm -rf ${RPM_BUILD_ROOT}\
%{nil}
With that, every time %clean is invoked in a spec file, it checks that
buildroot isn't /, and then deletes it if it is not.
However, that doesn't really resolve the deeper desire, which is as
Richard points out, is to remove the need to explicitly state the %clean
section at all. If we need to overload it beyond its defaults, we should
be able to invoke it manually and append to it, but if it is not set, it
should be invoked automagically.
RPM doesn't act this way. For all scriptlets, their absence does not
result in automatic invocation (there is no idea of always executed
default scriptlets in a spec), but instead is how they are omitted. I
can certainly see valid use cases where a package would not want %clean
to be invoked. It might be possible to change RPM's behavior to
introduce a disabler mechanism for default always executed scriptlets:
pseudocode
%disable %check
/pseudocode
This would be a significant behavior change for RPM, and not something
we could do with distribution specific macro tweaks. It would also break
backwards compatibility with older RPM spec files, which has
traditionally been avoided.
Another, perhaps simpler alternative would be making rpm inject default
%clean action when spec doesn't define one. To disable/customize the
default behavior, you'd just add an empty (or otherwise custom) %clean in
the spec, no special disabler logic required.
It is of course a change of behavior in rpm but allows getting rid of the
%clean section in 99% of specs and permits backwards compatibility too: if
you want to have %clean do (or not do) whatever you want, you just keep
the %clean section in the spec. It'd make those special cases stand out
clearly too, all you have to do is grep for %clean.
*
So, given those facts, and assuming that RPM isn't changing its
behaviors anytime soon, we can make macro changes in redhat-rpm-config
and change from this:
BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
...
%install
rm -rf %{buildroot}
make DESTDIR=%{buildroot} install
...
%clean
rm -rf %{buildroot}
...
TO:
...
%install
make DESTDIR=%{buildroot} install
...
%clean
...
Is anyone opposed to that?
No objections to BuildRoot and %install parts, but I'd suggest leaving
%clean out of it for the time being, as this is on direct collision
course with the above suggestion of built-in default %clean.
- Panu -
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
Re: mimehandler automatic Provides?
On Mon, 25 May 2009, Mamoru Tasaka wrote: Michael Schwendt wrote, at 05/25/2009 05:35 PM +9:00: Are they related to http://fedoraproject.org/wiki/Features/AutoFontsAndMimeInstaller ? Yes. audacity = 1.3.7-0.6.beta.fc11 Build Time 2009-03-02 16:40:30 GMT mimehandler(application/ogg) mimehandler(application/x-audacity-project) mimehandler(audio/basic) mimehandler(audio/x-aifc) mimehandler(audio/x-aiff) mimehandler(audio/x-aiffc) mimehandler(audio/x-wav) And in a later build they are not added anymore. audacity = 1.3.7-0.7.beta.fc11 Build Time 2009-05-13 08:50:08 GMT Searching the Wiki for mimehandler yields no results. I guess this is related to - https://bugzilla.redhat.com/show_bug.cgi?id=494817 - and file seems to have changed between these two days. Rpm changed too between these two, and that's what makes the difference here: tweak for something else broke this particular case. Note that Panu said that the above bug was fixed in F-12 rpm and actually 1.3.7-0.7.beta.fc12 has some mimetype Provides. Yup, the fix needs pulling into F11 too along with some others, but the fixes aren't quite critical enough to warrant requesting a freeze break and I dont really want yet another zero-day update either... but anyway an update to F11 rpm is pending sooner than later. - Panu - -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Agenda for the 2009-05-26 Packaging Committee meeting
On Tue, 26 May 2009, Rahul Sundaram wrote: On 05/26/2009 01:40 PM, Richard W.M. Jones wrote: On Tue, May 26, 2009 at 11:35:23AM +0530, Rahul Sundaram wrote: On 05/26/2009 09:50 AM, Jason L Tibbitts III wrote: The Packaging Committee will meet Tuesday, 2009-05-26 at 17:00UTC in the #fedora-meeting channel on chat.freenode.net. FPC works from the agenda at https://fedoraproject.org/wiki/Packaging/GuidelinesTodo; there's just one item currently on the agenda: Phase out Buildroot - https://fedoraproject.org/wiki/Phase_out_buildroot_tag_%28draft%29 How about phasing out Group tag as well? It seems like the Group tag is now optional in upstream RPM (since somewhere around F-11). Yes but there should be packaging guidelines adding a note that you can just drop it similar to built root. Does apt, smart and synaptic support comps though? do we care? Smart in GUI-mode and Synaptic currently use the Group tag to, well, group the packages for viewing: http://laiskiainen.org/tmp/smartpm-groups.png. Apt (and smartpm in cli-mode) dont care. Without spec specified Group they all get lumped under Unspecified but as the group tags are already wildly inconsistent, full of typos etc... dunno if it's such a big loss. - Panu - -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
