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.
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
