[Distutils] Instructions for bdist_rpm

[Harry Henry Gebel]

On Tue, May 02, 2000 at 08:57:27PM -0400, Greg Ward wrote:
> On 27 April 2000, Harry Henry Gebel said:
> > Will build an RPM using DistributionMetaData to get package
> > information. Additional information can be put in the file
> > 'package_data'. 'package_data' contains python code setting the following 
> > variables (variables marked with * are by default set from
> > DistributionMetaData and do not be need assigned in package_data unless
> > you need to override the values in .setup.py):
> 
> Yuck.  I like the idea that all meta-data is supplied in the setup
> script, but some of this stuff is obviously RPM-specific so really
> shouldn't clutter up the main DistributionMetadata class/object.  I
> think the answer is to put it in the mythical setup.cfg -- one more
> thing prodding me to go off and finish thinking through Distutils config
> files, argg!

I put it into a separate file to keep from putting RPM specific data in
setup.py, I just picked package_data as the name because I did not know
for sure what the current status of external configuration files in Distutils.

> > *name - name of package 
> > *version - package version
> > *summary - short summary of package
> > *description - long summary of package
> 
> Another yuck: description in setup.py -> summary in the .spec file, and
> long_description in setup.py -> description in the .spec file.  Oh well:
> name conflicts happen, that's just life.  I think the confusion can be
> localized to bdist_rpm.py, so it's not too bad.

Yea, I know. Unfortunately I didn't pick the names of the sections in a
spec file. I wasn't sure whether to pick names that matched the Distutils
meta-data or to pick names that matched spec file sections. I also thought
about not allowing the packager to override the values that are already
set in setup.py, if I disallowed this the whole issue would be moot. I am
leaning more towards taking those variables out since, for example,
overriding name or version would screw up the whole process (or at least
the automation of the process). In the next patch all the variables that
don't supply new data will probably be gone.

> > doc - a list of string containing names of files and directories to put in
> >       the system's documentation directory.
> 
> This should be initialized to ["README"] or ["README.txt"] (whichever
> one happens to be supplied).  The "sdist" command ought to make that
> information available, but there isn't really a clean way to get it now.
> Hmmm again.

Will do.

> > Unless otherwise noted these must all be strings. There is no type
> > checking yet, I would like people's opinion: should they be cast to
> > strings or should an exception be raised if they are not strings?
> 
> I would say definitely do type-checking, and do it in the logical way:
> require that everything be a string except:
>   * 'summaries' and 'descriptions' must be {string:string} dictionaries
>   * 'release' can be a number or a string

Okay, I only left it out pending a decision on what form it should take,
this will be in the next patch also.

> > 'package_data's local namespace includes the variable 'package_type' which
> > is set to 'rpm', this variable will hopefully allow 'package_data' to be
> > used for all bdist_* commands .
> 
> I think the right way to do this is to put these "not-quite-fundamental" 
> meta-data bits in the config file, in a "bdist" section (rather than a
> "bdist_rpm" section).  But that points back to me getting back to the
> config file stuff....
> 
> > 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.
> 
> 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.

> > tarball) saying around owned by root. The other caution is that the spec
> > file must be included in MANIFEST.in, otherwise it will not be included in
> > the tarball and therefore the tarball will not be buildable with rpm.

> If you're talking about the standard source distribution tarball, I
> don't think it *has* to include the .spec file: after all, the point of
> the "bdist_rpm" command is to 1) generate a spec file, and 2) optionally
> run some "rpm -b" commands on it.  Anyone who downloads the source
> distribution should be able to reconstruct the .spec file themselves
> using the "bdist_rpm" command.  Of course, then the module developer has

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.

`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.

> How about another option to generate a source RPM?  Not essential, but
> it just seems complete.  Plus it's generally considered nice to provide
> source RPMs when you provide binary RPMs.  I think it should be
> accessible like this:
> 
>     setup.py bdist --format=srpm
> or
>     setup.py bdist_rpm --srpm
> 
> Maybe --source-rpm or --source-only on that last one; not sure.
> 
> Also, should the normal output of "bdist_rpm" be just a binary RPM, or
> both binary and source RPMs?  If both by default, "--source-only" makes
> sense.

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`.

Did you read my post regarding CFLAGS, and what do you feel is the best
way to go on that issue?

-- 
Harry Henry Gebel, Senior Developer, Landon House SBS
West Dover Hundred, Delaware
PyNcurses ncurses binding for Python: http://pyncurses.sourceforge.ne