[Python-Dev] bdist_linux (was: setuptools has divided the Python community)
"Martin v. Löwis"
martin at v.loewis.de
Sun Mar 29 14:07:53 CEST 2009
> 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
The same is potentially true for RPM: if the files need to be layout
differently than the package author intended, automatic generation
of the spec file will also fail.
> I think this is the same rationale for debian packages. Right now people tend
> to use external tools like stdeb and they are OK with it (but still
> gets problems extracting stuff out of Python packages at this point)
Explicit is better than implicit: What is your list of problems with stdeb?
More information about the Python-Dev