|
|
Subscribe / Log in / New account

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




to post comments

Rawhide users: brace for a new RPM

Posted Jul 9, 2008 15:32 UTC (Wed) by cyperpunks (subscriber, #39406) [Link]

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

Posted Jul 9, 2008 16:51 UTC (Wed) by aleXXX (subscriber, #2742) [Link] (4 responses)

Does it support spaces in the paths now ?

Alex

Dual-arch handling

Posted Jul 9, 2008 18:02 UTC (Wed) by tarvin (guest, #4412) [Link] (3 responses)

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

Posted Jul 9, 2008 19:57 UTC (Wed) by spot (guest, #15640) [Link]

Is this filed as a bug anywhere?

Dual-arch handling

Posted Jul 10, 2008 10:22 UTC (Thu) by james (subscriber, #1325) [Link] (1 responses)

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

Posted Jul 10, 2008 17:10 UTC (Thu) by tarvin (guest, #4412) [Link]

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

Posted Jul 9, 2008 22:50 UTC (Wed) by epa (subscriber, #39769) [Link] (3 responses)

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

Posted Jul 9, 2008 23:04 UTC (Wed) by bojan (subscriber, #14302) [Link]

> 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

Posted Jul 10, 2008 5:25 UTC (Thu) by anchorsystems (guest, #40101) [Link]

> 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.

Patching and fuzz

Posted Jul 10, 2008 15:30 UTC (Thu) by iabervon (subscriber, #722) [Link]

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.

less fsyncs... maybe?

Posted Jul 9, 2008 23:51 UTC (Wed) by arjan (subscriber, #36785) [Link]

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

Posted Jul 10, 2008 1:40 UTC (Thu) by joey (guest, #328) [Link] (1 responses)

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

Posted Jul 10, 2008 12:15 UTC (Thu) by rahulsundaram (subscriber, #21946) [Link]

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. 


Copyright © 2008, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds