[pacman-dev] Can the update of a package induce the update of its depends?
Hi! When I was thinking on the symlink puzzle, I ran into the question above. Let me explain: Suppose, that an updated version of audacious moves from /usr to /opt; and user does a "pacman -S audacious". In this case the installed audacious-plugins will be broken, because it thinks that audacious is installed to /usr. The dir change of audacious wasn't planned so audacious-plugins simply depends on audacious (with no version number), so audacious-plugins won't be updated. To avoid this, the package maintainer can do some ugly tricks only (conflicts, install_script/warn etc.). So it would be useful, if the maintainer somehow could record to the repo that there was a big change between audacious 2.0-1 and 2.0-2; so if user updates from a <=2.0-1 version to a >=2.0-2 version this will induce the update of audacious' depends (we can assume, that the updated version of audacious-plugins works fine with the updated audacious.). Or we can define a special ("major") version number, whose change indicates a "recursive" update. Bye, ngaba ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program.
Hi! Oh, as you probably figured out, I meant inverse-depend (requiredby) here; sry. Bye, ngaba ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program.
On 7/5/07, ngaba@petra.hos.u-szeged.hu
and user does a "pacman -S audacious". In this case the installed audacious-plugins will be broken, because it thinks that audacious is installed to /usr. The dir change of audacious wasn't planned so
Users can't, and shouldn't, assume that they can cherrypick what software they update, and expect their system to work properly. The easiest solution, of course, is to merely make it well known that people should be doing -Syu to update and never -S. I think most users understand this. If you did want to handle this scenario for users, I think rather than having the maintainer have to deal with this, it'd be better to have pacman check if the package's dependencies have updates on a -S command also (e.g. pacman -S audacious implicitly means pacman -S audacious and any audacious deps). But again, users should be in the habit of upgrading their entire system. Scott
But again, users should be in the habit of upgrading their entire system. OK, of course, but I can imagine some specific "no net" or "low bandwidth" situations, where -S can be reasonable. Anyway, I think that pacman should be able to avoid all possible package/database inconsistencies (except if -d -or -f ... is used). At least a new option would be nice for this. Bye, ngaba
---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program.
On 7/5/07, Scott Horowitz
If you did want to handle this scenario for users, I think rather than having the maintainer have to deal with this, it'd be better to have pacman check if the package's dependencies have updates on a -S command also (e.g. pacman -S audacious implicitly means pacman -S audacious and any audacious deps). But again, users should be in the habit of upgrading their entire system.
I actually kind of like this behavior, and I know I've expected/wanted it at different points... I think it's definitely easier.... here's a use case: pacman -S bar (installs bar 1.0) ... bar is upgraded to 1.1 which means foo needs a recompile ... pacman -Sy pacman -S foo (installs the foo compiled against bar 1.1 but bar 1.0 is not upgraded). Now see, technically we can blame this on not using 'bar=1.1' in the deps, BUT we can't expect things like this all the time. I mean, in this case there is an OBVIOUS intent to mean that, it's just not written down.
participants (3)
-
Aaron Griffin
-
ngaba＠petra.hos.u-szeged.hu
-
Scott Horowitz