This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

classification
Title: packman upgrade issue
Type: enhancement Stage:
Components: macOS Versions:
process
Status: closed Resolution: wont fix
Dependencies: Superseder:
Assigned To: jackjansen Nosy List: jackjansen, ronaldoussoren
Priority: low Keywords:

Created on 2004-05-31 09:39 by ronaldoussoren, last changed 2022-04-11 14:56 by admin. This issue is now closed.

Messages (7)
msg20934 - (view) Author: Ronald Oussoren (ronaldoussoren) * (Python committer) Date: 2004-05-31 09:39
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
msg20935 - (view) Author: Jack Jansen (jackjansen) * (Python committer) Date: 2004-06-03 13:14
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.
msg20936 - (view) Author: Jack Jansen (jackjansen) * (Python committer) Date: 2005-01-04 16:03
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?
msg20937 - (view) Author: Ronald Oussoren (ronaldoussoren) * (Python committer) Date: 2005-01-04 16:34
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.
msg20938 - (view) Author: Jack Jansen (jackjansen) * (Python committer) Date: 2005-01-04 20:48
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.
msg20939 - (view) Author: Ronald Oussoren (ronaldoussoren) * (Python committer) Date: 2006-05-23 10:51
Logged In: YES 
user_id=580910

I propose closing this bug as WontFix, PackMan is dead in the water.
msg20940 - (view) Author: Ronald Oussoren (ronaldoussoren) * (Python committer) Date: 2006-06-11 09:16
Logged In: YES 
user_id=580910

PackMan was dropped in 2.5
History
Date User Action Args
2022-04-11 14:56:04adminsetgithub: 40313
2004-05-31 09:39:38ronaldoussorencreate