[Distutils] RPM questions

Harry Henry Gebel hgebel@inet.net
Fri, 2 Jun 2000 09:12:09 -0400

On Thu, Jun 01, 2000 at 09:38:49PM -0400, Greg Ward wrote:
> (Hey, I don't have a copy of the RPM book at home... and I have to mooch
> off someone else's at work.)

That's okay, the manual is horribly out of date anyhow (still based on RPM

>   * are the {pre,post}_{install,uninstall} scripts specified as
>     raw shell code or filenames?
>   * if raw code, d'you think it would be acceptable to specify them as
>     filenames for the Distutils instead of trying to deal with shell (or
>     Python!) code in a config file?

They are placed into the spec file as raw code, but it would probably be
better for the config file to refer to a file on disk, that saves from
having to work about multi-line strings (like package_data), etc. Then just
copy the contents of the file into the spec. Plus that way multiple
distribution formats could all refer to the same install/uninstall scripts
if appropriate.

>   * I'm punting on preserving the 'summaries' and 'descriptions'
>     dictionaries: either we craft a mapping syntax in config files, or
>     we expand 'description' and 'long_description' in the setup script
>     so they can be either a string (English description) or a dictionary
>     mapping 2-letter language codes to description in that language.
>     Opinions?

I was trying to think of the best way to put it in the config file, but
maybe the setup script would be better, certainly I think that Debian
support multiple locales and alot of other packaging formats probably do as
well, so it is something that has utility outside of just bdist_rpm.

>   * what is "prep" for?  is that a pre-build script?  is it basically
>     the same as {pre,post}_{install,uninstall}?

RPM wants source to be in the directory 'BUILD/package-version', the prep
script it a script that  unpacks the original source file or files and into
this directory and applies any patches. For most Distutils modules it will
'%setup' which is a macro that just extracts Source0 into BUILD.

>   * what should the default for "packager" be?  I initially made it
>     default to "vendor" (which in turn defaults to the "contact" from
>     the setup script, ie. maintainer if present, author otherwise), but
>     then I had a dim recollection that packagers can set their
>     name/address in an RPM config file.  True?  Should "packager"
>     default to nothing, so RPM fills it in?

Packager should be the person who is in charge of maintaining the RPM, it
should be left blank if there is no such person. This would be appropriate
for the [bdist_rpm] section of the config file since each packing format
will likely have somebody else in charge of it (at least if most developers
out there are like me and don't run a wide variety of operating

>   * should "release" be a string or a number?  I've never seen a Red Hat
>     RPM with a non-integer "release", but what're the rules?

Release can be any alphanumeric string, for example Mandrake RPMs start at
release '1mdk', then '2mdk', etc. I am using Helix Gnome and the release is
the unlikely string '0mdk_helix_1' (a very poor choice on Helix's part
IMHO). As long as the alphabetical portion remains the same RPM can still
keep the releases in order.
>   * what is "serial"?

This is for packages with version naming scheme that causes RPM to not be
able to put packages in the correct order; for example, RPM will classify
version 2.0b as being newer than 2.0 , if 2.0b is that package's way of
designating a beta release then RPM will complain about trying to install
an older release over a newer release when trying to upgrade to the final
release. If serial is specified then RPM ignores the version when it
figures out what packages are newer and older. Serial isn't used much
because once you start using it you have to keep using it forever if you
want RPM to keep putting your packages in the right order; most people
(like me) who use alot of betas and prereleases just learn to use
`rpm --force`.

>   * do you have an example Python module distribution that actually uses
>     most of the RPM options?  The Distutils distribution is pretty
>     simple, so I can't fully test "bdist_rpm" with it.

Nope, PyNcurses is also pretty simple. There are alot of python modules out
there, maybe somebody could point out a good one to experiment with? 

>   * is it really necessary to pass the "--define _topdir ..." to RPM?
>     Recall that this breaks under RPM 2.x, and since I *still* haven't
>     gotten around to upgrading my Red Hat 5.2 system, this bites
>     me.  (Who? me? procrastinating?)

This is being used to allow bdist_rpm to tell RPM where to find everything;
I asked both an this list and the RPM list if anyone knew a reliable way of
determining this but no one did so I was forced to specify  a specific
location. Unfortunately in RPM 2 there was no way of specifying  where to
put things on the command line, it had to be done in the rc file. And to
make matters worse RPM's internals were completely changed between RPM 2 and
RPM 3, and the changes resulted in different rc file formats. The only way
I can see to get around it for RPM 2 compatibility is to specify on the
setup.py command line the directories to use, then you could remove the
'--define topdir' option.

> OK!  Enough of that; the good news is, I've rebuild enough of
> "bdist_rpm" that we're back where we started, ie. it fails-to-work for me 
> just as it failed-to-work before I started ripping it apart.  IOW, it
> creates a reasonable-looking spec file, but dies because of the "rpm
> --define" option.  Well, guess what's next on my agenda.

I will test tonight to see if works with RPM 3.

Harry Henry Gebel, Senior Developer, Landon House SBS
West Dover Hundred, Delaware