2009/7/8 Nick Coghlan <ncogh...@gmail.com>: > Antoine Pitrou wrote: >> Nick Coghlan <ncoghlan <at> gmail.com> writes: >>> For example, I quite like the concept behind the various ideas for >>> "location" or "prefix" definitions either in the RECORD file itself or >>> in a separate PREFIXES file, since such approaches feeds directly in to >>> part b) above. >> >> I don't understand the point. Since RECORD is specific to a particular >> machine >> and installation (it is generated at install time), what would you gain by >> adding a fake genericity to its entries? > > My understanding is that RECORD isn't generated at install time for the > bdist_* commands -it's generated at the time the binary distribution is > created. Hence the problems raised with the idea of having absolute > paths in RECORD - if they were written directly into RECORD they would > reflect where the files were when the distribution was created, not > where they end up when it is installed.
This is a key open question, IMHO. No-one has done any work on updating the core bdist_xxx commands to the new structure, and the PEP is silent on the matter, so it's still all speculation. The current "best guess" assumption is that, given that bdist_xxx uses a "setup.py install --root=xxx" incantation to generate the structure to package, the RECORD can be picked up from this. There are a number of issues with this assumption, though - it doesn't handle absolute locations well (there are existing bugs), paths may be affected by the environment at the time the installer is built, and it requires RECORD to be relocatable. An alternative solution would be for the bdist_xxx commands to ignore the RECORD file generated in the temp area, and build its own on the target machine when the installer is run. This is conceptuially far cleaner, it's in line with the implicit assumptions in the PEP, and it avoids a lot of the problems with path formats (the filenames in RECORD could be absolute local pathnames, and that's the end of the story). But - and it's a big but - this dumps RECORD file handling on the bdist_xxx command, and they all need to implement the same code, resulting in a lot of duplication and opportunity for inconsistency. 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. There's also Phillip commenting from the setuptools POV and MAL who has mentioned his build process. Bottom line - Is RECORD to be created on the target machine at install time, or must it be relocatable? Subsequent question - if it's to be relocatable, how will that work? Paul. _______________________________________________ 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