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: Open
Resolution: None
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-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
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
