[ python-Bugs-963494 ] packman upgrade issue

[SourceForge.net]

Bugs item #963494, was opened at 2004-05-31 11:39
Message generated for change (Comment added) made by ronaldoussoren
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=963494&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Macintosh
Group: Feature Request
>Status: Closed
>Resolution: Wont Fix
Priority: 3
Submitted By: Ronald Oussoren (ronaldoussoren)
Assigned to: Jack Jansen (jackjansen)
Summary: packman upgrade issue

Initial Comment:
When you upgrade a package using packman the installer doesn't 
remove the old version before installing the new version. The end 
result is that old files might interfere with the correct operation of 
the upgraded package.

I ran into this with an upgrade from PyObjC 1.0 to PyObjC 1.1. 
Some extension modules have moved between those two releases. 
When upgrading using PackMan the old extension modules still 
exists, and cause problems when you try to use the package.

Three possible solutions:

1) Remove the existing package directory before installing the
    upgrade

2) Add pre/post install/upgrade scripts

3) Use a real package database

----------------------------------------------------------------------

>Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2006-06-11 11:16

Message:
Logged In: YES 
user_id=580910

PackMan was dropped in 2.5

----------------------------------------------------------------------

Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2006-05-23 12:51

Message:
Logged In: YES 
user_id=580910

I propose closing this bug as WontFix, PackMan is dead in the water.

----------------------------------------------------------------------

Comment By: Jack Jansen (jackjansen)
Date: 2005-01-04 21:48

Message:
Logged In: YES 
user_id=45365

I don't like the extra_path idea: it's meant for something else really. I 
think I'll just go for it and try the uninstaller trick. Don't know whether I'll 
have it in place before additions build 3, though, we'll see.

As to the other issue (missing dependencies and such): I want to solve 
that differently, eventually. Currently there's only one test (installed) per 
package that's supposed to be as cheap as possible. I want to have at 
least one more (consistency) and maybe even two (consistency and full 
selfcheck). But that'll have to wait.

----------------------------------------------------------------------

Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2005-01-04 17:34

Message:
Logged In: YES 
user_id=580910

That might work. It does require that packman installs dependencies 
before installing the package itself. 

Another problem is smart GUI's. One useful feature for a PackMan GUI 
would be a listing of missing dependencies (e.g. you've installed _tkinter 
and somehow didn't install AquaTk, it would be nice if PackMan said that 
AquaTk is missing). Such a feature would have to know about uninstall 
packages, otherwise it would complain that 'foo-uninstall' is missing after 
you've installed 'foo'.

Another solution (at least for PyObjC) is making sure that every package 
uses the 'extra_path' feature of distutils, add that value to the packman 
database, and remove $extra_path before installing a package. The 
extra_path key in the database could be optional: only add it when the 
previous version must be uninstalled before installing a new version.

----------------------------------------------------------------------

Comment By: Jack Jansen (jackjansen)
Date: 2005-01-04 17:03

Message:
Logged In: YES 
user_id=45365

All of these are difficult. But I was just wondering whether we could 
implement something simple: uninstall packages. For example, a 
package "PyObjC-uninstall" (normallly hidden) would somehow contain 
enough info to eradicate any known PyObjC installation. It's "installed" 
status would be true if PyObjC is *not* installed, false if it is.

PyObjC-1.3-{source,binary} could then depend on PyObjC-uninstall, and 
when the user installed either of these they would first "install" PyObjC-
uninstall, which would erase any previous installation.

An uninstall package would probably consist of a list of files and dirs that 
would need to be removed. The package would be flagged as "installed" 
if any of these exist.

There's probably packages that need something more complex (like 
editing config files or whatever), but I think this scheme would handle 
most common cases.

"installing" an uninstall package, possibly as a result of a dependency, 
should probably put up a warning dialog first.

Does this sound workable?

----------------------------------------------------------------------

Comment By: Jack Jansen (jackjansen)
Date: 2004-06-03 15:14

Message:
Logged In: YES 
user_id=45365

I'm moving this to the feature requests category: it requires major 
surgery, and it could be argued that this functionality belongs more in 
distutils than in Package Manager.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=963494&group_id=5470