[Python-Dev] PEP 376 - Open questions

[Eric Smith]

Antoine Pitrou wrote:
> Paul Moore <p.f.moore <at> gmail.com> writes:
>> I have no answer here. But I think we need feedback from the people
>> who will ultimately be building bdist_xxx formats - Debian packagers,
>> people wrting alternate RPM builders, etc.
> 
> I think any bdist_xxx command which targets externally handled package formats
> (rpm, deb, msi, etc.) shouldn't generate RECORD. If you install with rpm or
> dpkg, you will uninstall with the same tool, won't you?

I agree with this. For RPM's, there's a whole other database of what 
files were installed. Is it really the intent that a file will be 
managed by multiple different installers? That I can install with RPM 
but remove with some python-installer (or other) tool? That way lies 
madness. In fact, I see RECORD as an installer-specific detail that 
doesn't need to be standardized at all.

For bdist_rpm (which I'm contemplating taking over, but no promises), 
the only thing that needs to be done with the metadata is be able to 
build a .spec file. Once the .spec file is generated, rpmbuild (or 
equivalent) will produce the .rpm files. I image that .deb's are 
similar, but I'm no expert.

Which brings up the "static metadata" argument I was making at PyCon. I 
want there to be enough static metadata that the new bdist_rpm can read 
so that it produces a well-behaved .spec file. I need to know the intent 
of some of the files (which are documentation, which are config files, 
which are scripts, which are libraries, etc.) and not much else.

I envision the new bdist_rpm as a standalone tool, not a distutils 
extension.

>> Bottom line - Is RECORD to be created on the target machine at install
>> time, or must it be relocatable?
> 
> This is quite an uninformed opinion, but a relocatable RECORD looks like a can
> of worms to me.

Agreed.

> As for creating RECORD at install time, I don't understand the argument about
> duplicate code. Distutils can provide useful primitives for generating RECORD,
> so that interested subcommands don't have a lot of additional work to do.

I envision a "distlib" that contains new support code that's not part of 
the current distutils morass.