On Tue, Mar 25, 2008 at 5:16 AM, Floris Bruynooghe <[EMAIL PROTECTED]> wrote: > On Mon, Mar 24, 2008 at 10:35:01PM -0400, Phillip J. Eby wrote: > > At 12:33 AM 3/25/2008 +0000, Floris Bruynooghe wrote: > >> > 1. If the current installation state satisfies the requirements of a > >> > new package being considered for installation. > >> > 2. If it is safe for the administrator to upgrade or remove a package, > >> > and if so, how (e.g. use a system-level package management tool). > >> > 3. What files to remove in order to uninstall the package (if a > >> > system-level package management tool was not used to install it). > >> > 4. If the current installation was modified in-place or custom > >> > configured in an way, so that such changes can be noted before > >> > upgrading. > >> > >> I agree with 1 and 2, but 3 and 4 are optional I think. They are not > >> important for the different tools to interact AIUI. As long as > >> everyone only removes files they own all is fine. > > > > Not quite - it's necessary to know which files are owned by a given > > package or tool in order to do this. If you are installing a package, > > you need to know who owns any files that you're about to overwrite. > > What would the motivation be for requiring to overwrite files created > by another tool? That seems rather dangerous to me.
As different tools typically shouldn't be allowed to clobber each other, it seems both reasonable and a nice simplification for the proposed db not to require registering of installed files by all package managers/installers if an installer can choose to record its own lists in the db using a simple extension mechanism when desired. Nevertheless, it did seem nice to be able to ask the install db if the current state matches what is on disk by verifying the file lists and checksums against the file system, but this might be taking us too far into the abyss of recreating a system-level package manager.But an additional benefit is that requiring the file lists makes it easier to change tools by ignoring or rewriting the "ownership" information which I would tend to view as purely advisory in nature to begin with (i.e. no enforcement). Of course, this could be accommodated by establishing "standard" but optional auxiliary fields in the db that all python oriented tools would likely use. _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
