On Wed, 3 May 2000, Harry Henry Gebel wrote:
Subject: Re: [Distutils] Instructions for bdist_rpm
[snipping and probably losing who said what....]
bdist_rpm works by making a spec file and saving it into the 'redhat/' directory (making the directory if necessary), it then produces a gzipped source tarball and runs `rpm -ta --clean` on the tarball. bdist_rpm leaves the spec file and tarball around since they would probably be wanted anyway.
A couple of concerns: Redhat uses the /usr/src/redhat convention, Mandrake uses /usr/src/RPM so it's even worse than you noted. You could use rpm --showrc, but you'd probably end up (re)writing a parser to handle RPM macros, which would be just as bad as parsing the rpmrc (once you fond it). The -ta option is interesting. How does it handle patches? (see later on...)
Why does the .spec file need a directory of its own? The .spec is tiny and essential; I think it belongs right in the distribution root, like a setup script or a makefile. Any temporary by-products of "bdist_rpm"
I am not familiar with any packaging systems other than rpm and debian (and with regards to debian I am only familiar with it to the extent that is possible from browsing through the PyNcurses 'debian/' directory (which was contributed by someone else)). Not being familiar with other packaging systems I was a little afraid that another packaging system might have the same spec file naming convention as rpm and I didn't want them setting on each other. If this is not a concern I can change it to use the distribution root instead. I also thought it would fit in with the 'debian/' directory that the debian packaging system seems to use.
I don't know debian well, but pkgtool (Solaris and others) includes the spec file type info in the files pkginfo and pkgproto, with other script files also allowed. They are annoyingly ALWAYS THOSE NAMES so they CANNOT go into the same directory. By convention, they are not usually even included in the packages. HP-UX uses .psf files, but I think that's a convention, not a requirement.
The problem with not including the spec file is that I am using `rpm -ta` command rather than `rpm -ba` command. I am using this to get around the fact that the different distributions put rpm related files by default in different directories from each other, plus many users don't like to build RPMs as root and so set up their own directories for use with rpm. To use `rpm -ba` I would have to determine the location of the 'SOURCES/' directory and the only way I could figure out to do this was parsing the rpmrc, and this I did not want to do. Maybe I am missing an rpm command that spits this information out or allows you to define a specific source directory on the command line.
But still, don't you build the spec file from the distutil information anyway? That's going to be true of whatever package format the user requires, which, if it's not RPM the spec file is extraneous. I agree that figuring out the where's and what's of which rpm is going to be a nightmare...BUT, you can create a spec file with internal definitions for RPM_BUILD_ROOT, RPM_SOURCE_DIR, RPM_BUILD_DIR, etc, that does all the dirty work in /tmp, /var/tmp, or wherever, leaving only the final binary and/or source RPMS in the user's home directory. (That's my theory and I'm sticking to it untill someone points out an obvious error ;-). Anywhat, I strongly agree with supporting the creation of RPM's by non-root users. I just consider it safer, since it's pretty much impossible to step on a functioning installation.
`rpm -ta` takes a tarball containing a spec file and builds the RPM from that tarball and spec file. When the source RPM is produced the original tarball is placed in as the source file. Therefore, any source RPM produced with `rpm -ta` will contain a spec file in it's source tarball.
The convention in rpm (and this is repeatedly stressed in rpm development materials) is to use pristine sources ie. the exact source distribution you would get if you went and downloaded it from the author's site. If the spec file is not included in the standard source distribution then any source RPM produced with `rpm -ta` will by definition be in violation of this convention.
BUT, they also support inclusion and application of patches with the "pristine" sources in order to support the inevitable modifications of dealing with multiple distributions and platforms. (By the way, for those that don't know, RPM does run on non-Linux UNIX'es. It's not pretty trying to get dependency interaction with stuff already installed, 'though...) So the big question is does the -ta option support the inclusion of patch sets?
At the moment the default is to build both binary and source. rpm goes through the whole process whether you are building a binary or source rpm or both so I figured it would be better to just do both. Of course if there is a desire out there to only build one or the other I could easily add '--source-only' and '--binary-only' options that just call `rpm -ts` and `rpm -tb` instead of `rpm -ta`.
I positively vote either-or-whatever! The only consideration I see is if someone is extremely space tight. It takes moments longer to produce the source rpm. mwa