On Tue, 17 Jul 2001, Andrew Kuchling wrote:
[Picking up the package-DB thread from last week]
On Mon, Jul 09, 2001 at 03:17:35AM -0400, Daniel Berlin wrote:
This can easily be rebuilt in case of corruption, since *it* was generated initially by scanning the files (you just keep it up to date when you install packages, and if something gets out of whack, completely rebuild it).
The real package database implementation will very likely build a cached version of the data using anydbm or some faster mechanism. I don't think the PEP needs to specify that, though if people disagree it could certainly be added. I
This is starting to bother me even more than it did at first. If Distutils has a package database, and you use it to generate a native binary package, will the generated package update the distutils database, the native package manager's database, both, or neither? There's a whole boatload of problems no matter which answer you pick. The discussions so far have indicated to me that the primary problem is that the Windows platform has no true "native" manager. Does it make sense to provide this as part of Distutils for the sake of one platform, or does it make more sense to standardize on a installer for Windows that provides package management. Distutils bdist_win* packages would then be handled through a consistent interface that would register their contents properly. It could even go further, and properly manage multiple Python installations on the same machine, with different Distutils packages in each tree. Maybe I'm out in left field, here, but what exactly is the problem that this PEP is trying to solve? Every package manager I'm aware of covers all the questions in the "Requirements" statement, with the possible exception of "Where can I download a new version?" I always manage to find a place to stick that info (VENDOR, HOTLINE, or some such), so it _can_ be grafted into the PEP241 metadata usage for binary packaging. This is exactly why I wrote bdist_packager (patch #415226). So that module authors could provide metadata in a single unified manner which Distutils bdist commands can slice and dice appropriately for each supported package manager. Think about this, please. If you are going to continue a python repository of this scale, are you going to discontinue support for native binaries? It just doesn't make sense to do both. mwa