CPAN functionality for python
bsass at freenet.edmonton.ab.ca
Tue Feb 27 09:22:34 CET 2001
On Mon, 26 Feb 2001, Sean Reifschneider wrote:
> On Mon, Feb 26, 2001 at 02:56:51AM -0700, Bruce Sass wrote:
> >Do you mean:
> Ideally, it would be able to deal with both. The ability to download
> a distutils package and produce a .deb or a .rpm is more a function of
> the client program than of the archive network... It also largely depends
> on distutils as well.
So we are thinking along the same lines.
> >As for the second... it seems like an awful waste of archive space to
> >have the same code in many different formats, just because some want
> >to put stuff in /usr/share and others in /usr/lib, etc.
> I'm really not familiar with .deb packages. Howeer, for RPMs, if the
> author has included a .spec file in the tar file, you can simply run
> "rpm -ta foo.tar.gz" and the results will (should) be a compiled binary
> RPM. That is, if the author of the package has thought ahead about
> producing an RPM.
In a nutshell...
Debian's equivalent of a .spec is the "debian" subdir in the source
tree, containing administrivia and a "rules" makefile; doing
"debian/rules" compiles, "debian/rules binary" compiles and packages,
"debuild" compiles, packages and checks the package for errors and
conformance to Policy. There can be a lot more to it, but nothing the
author needs to worry about, in fact the author does not need to know
anything about Debian.
There are tools that create the debian dir and pull information from
the source tree to customize the package, it is very easy to script
so it can debianize anything thrown at it - provided the source tree
is reasonably consistent.
> The question becomes: Is it reasonable to require authors of packages
> for the archive network to do the same? Convince me it is...
No, it isn't. The authors should not need to know anything about the
final format of their module, just that they need to provide specific
pieces of information if they want to be included in the network
Hmmm, so RPM based systems don't have a way to automatically generate
a .spec file from a source tree... that would be a must.
More information about the Python-list