[Python-Dev] bdist_linux (was: setuptools has divided the Python community)

[David Cournapeau]

2009/3/29 "Martin v. Löwis" <martin at v.loewis.de>:
>> I think that each OS community should maintain its own tool, that complies
>> to the OS standard (wich has its own evolution cycle)
>>
>> Of course this will be possible as long as Distutils let the system
>> packager find/change the metadata in an easy way.
>
> In the specific case of RPMs, I still think that a distutils command
> is the right solution. It may be that bdist_rpm is a bit too general,
> and that bdist_fedora and bdist_suse might be more useful.
>
> It all comes down to whether the .spec file is written manually or not.
> *If* it is written manually, there is IMO no need to have the packager's
> metadata readily available. Whoever writes the spec file can also look
> at setup.py. OTOH, if the spec file is automatically generated, I can't
> see why a bdist_ command couldn't do that - and a bdist_ command can
> easily get at all the package (meta) data it needs.
>
> So in this case, I think separate access to the meta-data
> isn't needed/doesn't help.
>
> For bdist_deb, things might be different, as the packager will certainly
> want to maintain parts of the debian/ directory manually; other parts
> would be generated. However, I still believe that a bdist_ command would
> be appropriate (e.g. bdist_dpkg). As I understand Matthias Klose, the
> tricky part here is that the packaging sometimes wants to reorganize
> the files in a different layout, and for that, it needs to know what
> files have what function (documentation, regular package, test suite,
> etc). If that file classification isn't provided by the package author,
> then there would be still a manually-maintained step to reorganize the
> files.

Maybe I don't understand what is meant by metadata, but I don't
understand why we can't provide the same metadata as autotools, so
that distutils could be customized from the command line to put data
where they belong (according to each OS convention). So that making a
FHS compliant package would be as simple as

python setup.py distutils --datadir=bla --htmldir=foo ....

I spent some time looking at cabal this afternoon ("haskell
distutils"), and from my current understanding, that's exactly what
they are doing:

http://www.haskell.org/cabal/release/cabal-latest/doc/users-guide/authors.html#pkg-descr

This way, if some metadata are not provided by upstream, the
downstream packager can fix it, and send patches upstream so that
other packagers benefit from it.

(FWIW, from the reading of cabal documentation, it looks like cabal
provides everything I would like distutils to provide: static
metadata, good documentation, sane handling of options, etc... Maybe
that's something worth looking into as inspiration for
improving/fixing distutils)

cheers,

David