CPAN functionality for python

[Bruce Sass]

On Mon, 26 Feb 2001, Sean Reifschneider wrote:
> On Mon, Feb 26, 2001 at 11:14:35AM -0700, Bruce Sass wrote:
> >from outside the archive.  The translation from a generic pkg to a
> >distro specific pkg would be a problem for the disto to solve
> >(probably a matter of repacking info about the pkg, then using
>
> The only way having automaticly-generated packages be possible is
> if we really force a conformance from the authors of the packages.
> I've packaged quite a number of RPMs in my day, and you can get pretty
> close to just wrapping a tar file with some meta-information in
> some cases, but these are the minority.

I have assumed that submitted packages would need to meet a
standard of some sort - was that incorrect?

> In most cases you have to provide patches which fix incorrect paths
> in the tar file (for example, the Python tar file uses
> "#!/usr/local/bin/python" all over the place).

That is to be expected... and only the distro is really equipted to
handle these issues.

> If we can force the distributions to be more compatible with being
> packaged, it may be very easy.  Otherwise, we may have to rely on
> people contributing their time to building RPMs if we want to have
> RPMs.

I'm not sure what you mean here.  The distributions are the ones doing
the packaging, the Python version of CPAN should supply all the bits
needed for the distros to perform that function.

> >only way I can see to do that is to not package to anyones spec, but
> >provide enough information so that anyone can package to their
> >fav spec.
>
> I don't agree...  I believe that we should embrace the different packaging
> formats, not act like they don't exist.

Maybe we see "embracing" them a little differently.  I believe
providing everything they need to turn a Python module/package into
their standard format, using their packaging and QC tools, does them
more of a service than providing pre-built packages created by a third
party.  I'm not saying binary style packages shouldn't be supported,
just that the emphasis should be on portable (in that they can easily
be turned into a system's native pkg format) source packages.

> If the distutils package can be
> made to generate native RPMs, that's great.  The *CLIENT* program should
> dictate that.  If it can handle turning a distutil package into an RPM,
> it'll have it's preference be a distutil package.

That sounds like exactly what I was enquiring about - as long as the
distutils pkg provides enough info for every distro to create their
own pkg.

> I don't believe having the archive not able to deal with different package
> formats is acceptable.  If that were the case, then if the package didn't
> provide enough information to build an RPM, the user would have no option
> within the archive of working around it.

Agreed.  The submission should not be accepted if it does not contain
enough information to be packaged.


- Bruce