[Distutils] [Python-Dev] How we can get rid of eggs for 2.6 and beyond

[Alexander Michael]

On Tue, Mar 25, 2008 at 5:16 AM, Floris Bruynooghe
<floris.bruynooghe at gmail.com> 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.