Archive for July, 2007

YUM and CTRL-C

Wednesday, July 25th, 2007

To clear up any false expectations: Rahul, contrary to what you wrote, RPM 4.4.2.1 doesn’t “fix the YUM CTRL-C issue”. If you read carefully what I said, that work has been done in rpm.org development branch, and will almost certainly be backported to the 4.4.x branch in the next maintenance release.

That said, the relevant patches are already included in Fedora Development RPM and thus will be in Fedora 8 starting from test1. But the RPM part is just an enabler, additionally YUM needs to make use of the new rpm-python methods before CTRL-C (and other normal exit signals) start working as expected. Initial patch to do this has just gone into YUM upstream but by the looks of things, F8-test1 wont yet have it as test1 has just been frozen.

Update: Seth says that thanks to a hiccup in the test spin he was able to slip the patch into test1 after all, excellent…

RPM 4.4.2.1 and the way forward

Monday, July 23rd, 2007

At a long last, RPM 4.4.2.1 is finally out after three release candidates and several weeks of testing in Fedora Development repository. It’s only a maintenance release, but rather significant in that it is the first RPM release from rpm.org since the “upstream reboot” in December 2006. For the glory details, see the 4.4.2.1 announcement on rpm-announce list.

Many moons have passed since 4.4.2 release, and thus the list of included fixes and cleanups is longer than one would perhaps otherwise expect from a minor maintenance release such as this. The list could’ve easily been much longer, but there’s a limit in how many changes one wants to include in what’s supposed to be a very stable and mature release. And besides, while the main focus will now be in the next major release, it’s quite likely that we’ll put out another minor maintenance release in the meantime to bring in some of the accumulated work from rpm.org development branch. Such as the support for getting YUM to honor CTRL-C again…

Oh and naturally the new version is soon to be found in Fedora Development repository, and eventually will be made available as an update to at least Fedora 7 and possibly Fedora Core 6 too.

509 compiler warnings later

Tuesday, July 10th, 2007

Spent most of today fixing up things that cause gcc to whine about RPM source. Comparing rpm-4.4.2.1-rc3 vs current rpm.org head:

[pmatilai@localhost rpm]$ grep warning build.warnings.4421|wc -l
871
[pmatilai@localhost rpm]$ grep warning build.warnings|wc -l
362

Of the remaining 362 warnings, 252 come from Berkeley DB, so just over 100 more warnings to deal with still in actual rpm code. Of those, roughly a third come from debugedit.c alone… In any case, the build looks a whole lot less scary than it used to. Another big cleanup-round or two (these numbers are with -fno-strict-aliasing, removing that reopens another can of worms) and it might start to be possible to actually spot warnings from new code as it gets written.

Panu’s Big Mistake

Friday, July 6th, 2007

Noticed with some amusement that “my” decision to revert the provides as implicit obsoletes behavior in rpm.org has been classified as “Panu’s Big Mistake” at rpm5.org: http://rpm5.org/cvs/chngview?cn=7632

Jeff has been insisting that the implicit obsoletion is intended and desirable feature but everybody else disagrees – if you look at various distributions shipping rpm >= 4.2, practically all of them have reverted that particular change. Except for Red Hat, and if you know a little bit about RPM history, it’s not hard to guess why. Yes, RH based distros have survived this four year period, but there have been endless complaints about the behavior. Some from surprised users, but mostly from packagers who find the implicit obsoletes very much unexpected and frustrating behavior as it prevents all sorts of otherwise useful packaging schemes. It hurts especially compatibility packages but there are other cases as well.

Sure, it was me who eventually applied the behavior reverting patch, but only following a lengthy discussion on the matter where the only concern people really had was the timing of the change, not the change itself. Various folks have been actually applausing the decision. The mistake here is firmly in the eye of the beholder…

RPM and %patch

Tuesday, July 3rd, 2007

Having seen DaveJ’s recent comment on RHEL-4 kernel having over thousand patches applied, I had this nasty feeling I’d seen a comment somewhere in the %prep parsing of rpmbuild stating “we can only handle 1024 patches!” And sure enough, there it is in parsePrep.c… yet all the 1076 patches are applied.

Turns out there’s a little known feature in the %patch “macro”: it can take several patch numbers at once, and that’s what the 1024 patch limit is about. You can use it like this: “%patch -p1 1 2 3 4” instead of having four separate %patch lines.

Except that it’ll probably tell you “error: No patch number 0” because %patch is treated as %patch0. So the above should be “%patch1 -p1 2 3 4” to actually work. What a wonderfully broken feature, ugh.