News from other worlds

I was recently forced to face once more the limitations and quirks of rpm. This is more painful, when looking at a more capable system like .deb.

When building a .deb package, the debian/rules file is pretty much the heart of all things happening, with debian/control and debian/changelog as the lungs and the liver(? maybe) .

Having different files for the maintainer scripts makes possible things like automatic (but repetitive) generation/modifications of those scripts. This can be useful in some situations when the postinst should do stuff depending on the current contents of the released upstream source (sorry, I know I am being vague, but I can't detail too much). The source package is then generated and the resulting package can be rebuilt 1000 times and the resulting postinst will not be different for a given release. But this is always done in the same way, no matter the upstream version.

Fatality one - the spec is fixed, saint, but still can be altered... still, not in due time

So the basic idea is to have postinst.in as a source for postinst, which is created during the configure stage and later removed on clean. This is possible and works on deb.

Try the same on rpm and you will fail. This is because, although the spec file supports file inclusions, the altered files are merged into the spec right at the beginning of the build process, and you end up with no or an outdated postinst. A later rebuild of the same package would do the trick, but that is wrong for more than one reason.

Fatality two - why fatality one was met

All of this is made in order to overcome yet another rpm limitation: rpm can't assist too much on upgrades; you can't simply upgrade packages properly from one version to another, because rpm doesn't have the notion of letting the scripts know which version is installed over which; it only tells that it is an upgrade or not.

This has lead some people believe rpm isn't able to upgrade at all. Glad to tell them they're wrong (still rpm sucks and is brain dead).

Fatality three - why rpm based system fail to have upgrade support today

Want another RPM limitation? RPM has this brain dead idea that on upgrade the "proper" order and way to call the maintainer script(lets) is:

• new-preinst 2
• new-postinst 2
• old-prerm 1
• old-postrm 1

The numbers 1 and 2 are literally what is passed to the scripts and mean "the number of the installed versions of the same package that will exist after the current operation finishes". No versions of any kind, no other parameters, no rollback, no nothing, just 1 or 2.

And by letting the scripts of the old version run AFTER the scripts of the new one means that you have to explicitly prepare the packages for a later upgrade support (and the best idea is to do NOTHING in the old prerm and postrm scripts on upgrades, since nobody is clairvoyant to see what would be the right course of action for upgrade in future releases).

More bad ideas from the rpm land (glad not to be there)

In somewhat related news, the fedora people are discussing now around the rejection of being able to have package names contain non-ascii characters, characters like kanji, kanas, cyrillic characters or any other characters. Even if I am pro-l10n, this wreaks of bad idea scent from a mile afar.

They aren't probably aware that even unicode is broken (if you see the same glyphs in the comparison table, that is proof unicode is broken) but that is their decision and I am glad I am not in that lost land.

More "RPM argh" or how to use %includes properly

It turns out that if you want to use includes in your .spec file and want the files to be included in the .src.rpm you have to declare those scripts as supplemental sources.

So instead of:
Name: foo
Version: x.y
Release: z
Summary: foo package
Group: Applications/System
Source: foo.tar.gz
Packager: Eddy Petrisor
BuildArch: noarch
BuildRoot: $RPM_BUILD_ROOT
....


You have to have:

Name: foo
Version: x.y
Release: z
Summary: foo package
Group: Applications/System
Source: foo.tar.gz
Source101: foo.pre.sh
Source102: foo.post.sh
Source103: foo.preun.sh
Source104: foo.postun.sh
Source105: foo.changelog
Packager: Eddy Petrisor
BuildArch: noarch
BuildRoot: $RPM_BUILD_ROOT
....

In case you want to have the scripts separated in different files and you use them all.

Note: the number in the "SourceXXX" is arbitrary but must be unique.

But mentioning the files as being Source... means you have to write:


%post
%include ../SOURCES/foo.post.sh

%preun
%include ../SOURCES/foo.preun.sh

%postun
%include ../SOURCES/foo.postun.sh


Instead of:


%post
%include foo.post.sh

%preun
%include foo.preun.sh

%postun
%include foo.postun.sh


Which should have been more reasonable...

RPM, please die... or grow some 21st century features... or some sense!!!


Update: Thanks to a few people, I was pointed out I am still not thinking in terms or RPM.
The proper way of writing the include without them looking odd is something like:

%post
%include %{SOURCE102}

RPMs, gaaaaaah!

Always when I have to deal with RPM systems I feel so handicapped and it feels so wrong from multiple PoV.

This is a rant and a dear lazyweb (not that lazy, actually) type of post.

I would like to be able to have a few things solved when dealing with RPMs:

1. I would like a pbuilder like builder for specs
• I know about mock, but
• it accepts only src.rpm files (I know about rpmbuild -bs, but is broken, read further for the groovy details)
  
• I have some specs that have %include directives for the maintainer scripts and when rpmbuild -bs is ran, guess what, the extra files are left outside the src.rpm;oh yes, the directives are processed correctly for the binary rpm
• mock relies on bootstrapping a system using fedoralegacy.org, which was recently discontinued
• I have a redhat-9 chroot tarball which I would like to use and tell mock to use that without caring about upgrades (since my packages are not at all that dependent on the build system)
• mock fails to bootstrap even for fedora-devel-i386-core with the message "Cannot find a valid baseurl for repo: extras"
• the older versions fail to bootstrap because, apparently, it "Could not find useradd in chroot, maybe the install failed?"
• plague (how's that for irony?) relies on mock, which is broken
• mach seems to be deprecated
2. I would like a simple repo creation and maintainance tool, something in the line of mini-dinstall, which should have apt4rpm and yum support, but it seems that repos are still the "new shiny thing" which has no proper tools
3. I would like to be able to know from which version I am upgrading from the current package, not only that I am upgrading (in case you didn't knew, the only way to know that you are upgrading in a post/pre install/remove script, is the wonderful $1 parameter which indicates the number of packages installed after the script finishes or something along that line..
   

So my question is, is there any way to fix any of the issues above in a sane way, without me reimplementing apt-like functionality in rpm land?