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

* 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 systems/distributions).

* 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