Rawhide users: brace for a new RPM
From: | Panu Matilainen <pmatilai-AT-redhat.com> | |
To: | fedora-devel-announce-AT-redhat.com | |
Subject: | Heads-up: brand new RPM version about to hit rawhide | |
Date: | Wed, 9 Jul 2008 13:51:15 +0300 (EEST) | |
Message-ID: | <alpine.LFD.1.10.0807091240400.20166@localhost.localdomain> | |
Cc: | fedora-devel-list-AT-redhat.com |
At long last, we are about to get a brand new RPM version (alpha snapshot at the moment) into rawhide. The list of changes from 4.4.2.x is massive and a full summary needs a separate posting (will follow as time permits), this is just a heads-up of immediate consequences for Fedora packagers and rawhide consumers: Users: 1) BACKUP YOUR RPMDB, NOW! We're not aware of any baby-eating bugs in rpm but I'd be shocked if there were no new bugs at all... Better safe than sorry - do something like this before updating to the new rpm: # cp -avp /var/lib/rpm /var/lib/rpm-`date +%d%m%y` 2) Rebuilding the rpmdb is not a bad idea (if not strictly necessary): # rpm --rebuilddb 3) Watch out for regressions and please report immediately if found. Again, we're not aware of any baby-eating bugs but there has been an enormous amount of changes in the codebase... The python bindings are supposed to be entirely backwards compatible but there are some small differences with returned types (notably returning an empty list vs None) on tag data in some cases, this breaks rpmlint (patch is trivial, will send to maintainer). Packagers: 1) So-name bumb is involved, the API has changed a lot. Here's the list of involved packages according to repoquery and status, I'll be sending patches to package maintainers shortly: - gdb (needs update to locate build-id patch) - perl-RPM2 (needs some updating) - apt (needs major work, but this is my headache) - ruby-rpm (needs quite a bit of work) - deltarpm (just needs a rebuild apparently) - net-snmp (needs rebuild with -D_RPM_4_4_COMPAT) - rpmreaper (needs rebuild with -D_RPM_4_4_COMPAT) 2) rpmbuild uses --fuzz=0 parameter to patch by default. This will "break" many many packages as this is stricter than the default of patch command itself. Two possibilities: - Rediff your patches and check they're applying correctly. This is the best thing to do, patches applied with fuzz can and do cause strange and nasty bugs. - As a temporary action, adding "%define _default_patch_fuzz 2" to spec will force rpm to use fuzz level 2 which is the default for patch itself. 3) %{_topdir} now defaults to $(HOME)/rpmbuild/, /usr/src/redhat/ is no more. 4) BuildRoot from spec is ignored. Rpm now defaults to buildroot under %{_topdir}/BUILDROOT/ 5) Rpm now supports "arch dependencies", so eg. foo-devel dependencies can be expressed correctly. Please wait for FPC recommendations on the subject, this needs a mass rebuild to be usable. 6) Rpm now collects pkg-config and libtool dependencies automatically. Initially only provides will be created to avoid creating unsolvable dependencies though. 7) Two new macros, %{patches} and %{sources} are supported in rpmbuild. In other words, you can now do things like: for p in %{patches}; do ... done Just keep in mind that using these in your spec will make the it incompatible with rpm 4.4.x versions. P.S. The new rpm will be initially built against Berkeley DB 4.5.20 from compat-db to ensure easy downgrade path to rpm 4.4.x should something go terribly, horribly wrong. Newer BDB would require manual db conversion to downgrade. - Panu - -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Posted Jul 9, 2008 15:32 UTC (Wed)
by cyperpunks (subscriber, #39406)
[Link]
Posted Jul 9, 2008 16:51 UTC (Wed)
by aleXXX (subscriber, #2742)
[Link] (4 responses)
Posted Jul 9, 2008 18:02 UTC (Wed)
by tarvin (guest, #4412)
[Link] (3 responses)
Posted Jul 9, 2008 19:57 UTC (Wed)
by spot (guest, #15640)
[Link]
Posted Jul 10, 2008 10:22 UTC (Thu)
by james (subscriber, #1325)
[Link] (1 responses)
Posted Jul 10, 2008 17:10 UTC (Thu)
by tarvin (guest, #4412)
[Link]
Posted Jul 9, 2008 22:50 UTC (Wed)
by epa (subscriber, #39769)
[Link] (3 responses)
Posted Jul 9, 2008 23:04 UTC (Wed)
by bojan (subscriber, #14302)
[Link]
Posted Jul 10, 2008 5:25 UTC (Thu)
by anchorsystems (guest, #40101)
[Link]
Posted Jul 10, 2008 15:30 UTC (Thu)
by iabervon (subscriber, #722)
[Link]
Posted Jul 9, 2008 23:51 UTC (Wed)
by arjan (subscriber, #36785)
[Link]
Posted Jul 10, 2008 1:40 UTC (Thu)
by joey (guest, #328)
[Link] (1 responses)
Posted Jul 10, 2008 12:15 UTC (Thu)
by rahulsundaram (subscriber, #21946)
[Link]
Rawhide users: brace for a new RPM
Thanks Panu! Great to see nice improvements in such an important part of the tool chain, which
as been moving slowly the last years.
Rawhide users: brace for a new RPM
Does it support spaces in the paths now ?
Alex
Dual-arch handling
The current Red Hat/Fedora RPM wreaks havoc on your x86_64 system if you clean out the
i[356]86 packages:
Let package X be a package which exists in both an x86_64 and i386 version, and both are
installed during system installation. Let X contain both arch-dependent and arch-independent
files. An arch independent file could be /usr/share/locale/xx/LC_MESSAGES/foo.mo. If you
remove X.i386, X.x86_64 will suddenly be broken, because RPM removed
/usr/share/locale/xx/LC_MESSAGES/foo.mo.
I hope the new RPM handles this in the obvious way: When removing a package, don't remove a
file if it's also part of another, not-removed package.
Dual-arch handling
Is this filed as a bug anywhere?
Dual-arch handling
Which versions are you seeing this with?
This bug certainly *used* to exist, but it got fixed a couple of Fedora releases ago.
Dual-arch handling
Sorry - it seems you are right: recent Fedoras aren't affected. But RHEL 5.2 was last time I
checked (a week ago).
Patching and fuzz
Interesting that applying patches with fuzz is no longer allowed. Essentially this means that
patches must be regenerated against each new upstream version (though a simple script can
automate that and show the results for checking). The logical next step would be to take an
md5sum of the source file before and after applying the patch, so it can apply only to the
exact version.
Indeed, pristine sources are a good idea but the rpmbuild tool is a slightly odd place to
apply the patches. Eventually a better way would be to use the distributed VCS of your choice
to maintain a source tree with your packaging customizations and pull the upstream sources to
it every so often.
Patching and fuzz
> Interesting that applying patches with fuzz is no longer allowed.
Only by default. This can be overridden by packages.
> Essentially this means that patches must be regenerated against each new upstream version
Only if there is fuzz. Otherwise, no.
Patching and fuzz
> Indeed, pristine sources are a good idea but the rpmbuild tool is a slightly odd place to
> apply the patches. Eventually a better way would be to use the distributed VCS of your
choice
> to maintain a source tree with your packaging customizations and pull the upstream sources
to
> it every so often.
Argh. That would be an absolute nightmare for collaboration and reuse by
others.
The great thing about source RPMs is that it is trivial for any third party to
see how the source differs from the upstream version. That makes it easy to
update to newer (or older) upstream versions, remove/update old patches, or
to pick up/review patches for upstream integration.
I think you're confusing fuzz and offsets. You only get fuzz if there are differences between the version you have and the version the patch was against in the 3 context lines around each change. My vague estimate is that, if a patch applies with fuzz, there's about even odds that the resulting code will work, versus being broken in some way. In particular, if there's a memory leak, and you make a patch to fix it, and the upstream adopts your patch, your patch will probably apply with fuzz and introduce a double-free bug.
Patching and fuzz
less fsyncs... maybe?
I really hope they managed to remove the fsync/fdatasync's that happen all the time at high
frequency during installation (one at the very end is understandable obviously)... that'll
make rpm orders of magnitude faster.
Rawhide users: brace for a new RPM
4) BuildRoot from spec is ignored. Rpm now defaults to buildroot under
%{_topdir}/BUILDROOT/
This change will break alien. Why do the rpm maintainers delight in making this kind of
change? Why do I bother keeping alien working? Meh.
Rawhide users: brace for a new RPM
The new default is certainly better than every spec file having to define it's own buildroot
and it was already discussed in the RPM development list where concerns should have been
raised. It wasn't done to break alien you know. You should work with the RPM maintainer to
resolve the problem. This is still a alpha snapshot and you can still redefine the default.