[pacman-dev] [GIT] pacman branch, master now at v3.0.0-419-g012f793
Hello,
This is an automated email from the git hooks/update script, it was
generated because a ref change was pushed to the repository.
Updating branch, master,
via 012f7939784358b02726c169543aa99436439335 (commit)
via 843d368ef60a74719dfc74a27de3fe3ef441951f (commit)
via 105fd40a4a9b221df0186e7500fe491b3b96d823 (commit)
via 6898bb0f9742e078f2c45609cf00d43438a14843 (commit)
via 8acb6d24af81d57ed87339aaf3472bda28b3a38d (commit)
via d3c80030201b555efba2f31811cff627a3fdeaf8 (commit)
via 443950b7e9c40493a184d55caaa71c2b4daa3ffd (commit)
via f9b7c67d24210dc4b2c77b751948e0f17f80583f (commit)
via 1860ab898086096ef0d9aad66e29f86cbf271423 (commit)
from 7325ebbc22091c698fd19140b7ed6986024ec6e8 (commit)
- Log -----------------------------------------------------------------
commit 012f7939784358b02726c169543aa99436439335
Author: Dan McGee
Add sync044 pactest : A dependency induces a replacement.
That is the problem mentioned by Nagy there (with suggestions for fixing it) : http://www.archlinux.org/pipermail/pacman-dev/2007-August/009082.html
If a dependency conflicts with a local package and has to replace it, the PM_SYNC_TYPE_DEPEND information is lost, and the resulting install reason is wrong (the package is marked as explictly installed).
Signed-off-by: Chantry Xavier
Well, this should be fixed with http://www.archlinux.org/pipermail/pacman-dev/2007-September/009271.html Please follow the thread, and let me know your -U and -S opinion (there are 2 different ways: the Vmiklos-way and the ~Arch-way). If I get enough feedback, I will implement your choice. My opinion: -%REASON% should show the _initial_ reason (which is computed after the _first_ install of the package), and later -S/-U will keep this reason (without examining that this is a pulled dependency, or listed in the target list by user) [this is the ~Arch way]: I prefer this, because [1.] if the user don't want to update his whole system with -Su (because he has low-bandwidth net for example), he can update a dependency (by doing "pacman -S dependency") without change its reason field to explicit; [2.] and unneeded dependency->explicit conversion may prevent pacman from orphan detection (can happen in Vmiklos-way) and missing dependency->explicit conversion just may list some extra orphan packages (can happen in ~Arch-way); [3.] explicit is the "final"/irreversible state of a package -IMHO we need an ability to change the reason fields in localdb /whatever you choose/, because users may want to mark/unmark their "important" packages (and pacman's automatism is unpredictable ;-) Bye, ngaba ---------------------------------------------------- SZTE Egyetemi Könyvtár - http://www.bibl.u-szeged.hu This mail sent through IMP: http://horde.org/imp/
On Mon, Sep 24, 2007 at 01:19:58PM +0200, Nagy Gabor wrote:
Well, this should be fixed with http://www.archlinux.org/pipermail/pacman-dev/2007-September/009271.html Please follow the thread, and let me know your -U and -S opinion (there are 2 different ways: the Vmiklos-way and the ~Arch-way). If I get enough feedback, I will implement your choice.
What about this for -S and -U : * on first install of a package, mark it as explicit if it's in the original targets, and otherwise as dep. * on an upgrade, keep the previous reason (this behavior could be overriden using --asexplicit and --asdeps flags).
What about this for -S and -U : * on first install of a package, mark it as explicit if it's in the original targets, and otherwise as dep. * on an upgrade, keep the previous reason (this behavior could be overriden using --asexplicit and --asdeps flags). This is exactly the ~Arch way ( == my opinion). Bye, ngaba
---------------------------------------------------- SZTE Egyetemi Könyvtár - http://www.bibl.u-szeged.hu This mail sent through IMP: http://horde.org/imp/
Well, this should be fixed with http://www.archlinux.org/pipermail/pacman-dev/2007-September/009271.html Please follow the thread, and let me know your -U and -S opinion (there are 2 different ways: the Vmiklos-way and the ~Arch-way). If I get enough feedback, I will implement your choice. My opinion: -%REASON% should show the _initial_ reason (which is computed after the _first_ install of the package), and later -S/-U will keep this reason (without examining that this is a pulled dependency, or listed in the target list by user) [this is the ~Arch way]: I prefer this, because [1.] if the user don't want to update his whole system with -Su (because he has low-bandwidth net for example), he can update a dependency (by doing "pacman -S dependency") without change its reason field to explicit; [2.] and unneeded dependency->explicit conversion may prevent pacman from orphan detection (can happen in Vmiklos-way) and missing dependency->explicit conversion just may list some extra orphan packages (can happen in ~Arch-way); [3.] explicit is the "final"/irreversible state of a package -IMHO we need an ability to change the reason fields in localdb /whatever you choose/, because users may want to mark/unmark their "important" packages (and pacman's automatism is unpredictable ;-)
Bye, ngaba
As I started thinking about the implementation, I ran into some older questions, which we haven't discussed yet; but it is necessary to make decisions, because the they affect the solution of this problem, too. 1. Should we resolve target<->target conflicts by removing the package from the target list? I started to like Xavier's opinion ( == no, we shouldn't), because I realized that if we don't resolve them, then we don't(?) need pmsyncpkg_t struct. [my answer: dunno, Xavier: no] 2. So shall I kill pmsyncpkg_t struct? [my answer: yes; however, this is a big job; but this is the first step we need if we want to implement the "universal" transaction; contra: we loose the "glue" between the replacer and the to-be-replaced packages <- so the real question is: do we need this glue?] 3. %REASON% handling [my answer, Xavier: ~Arch-way] Bye, ngaba ---------------------------------------------------- SZTE Egyetemi Könyvtár - http://www.bibl.u-szeged.hu This mail sent through IMP: http://horde.org/imp/
As I started thinking about the implementation, I ran into some older questions, which we haven't discussed yet; but it is necessary to make decisions, because the they affect the solution of this problem, too.
1. Should we resolve target<->target conflicts by removing the package from the target list? I started to like Xavier's opinion ( == no, we shouldn't), because I realized that if we don't resolve them, then we don't(?) need pmsyncpkg_t struct. [my answer: dunno, Xavier: no] 2. So shall I kill pmsyncpkg_t struct? [my answer: yes; however, this is a big job; but this is the first step we need if we want to implement the "universal" transaction; contra: we loose the "glue" between the replacer and the to-be-replaced packages <- so the real question is: do we need this glue?] 3. %REASON% handling [my answer, Xavier: ~Arch-way]
Bye, ngaba
Now I explain, how I imagine the universal transaction. There would be only one transaction type (universal, so type is unneeded ;-), with an install and remove list. There would be 3 type of loadtarget, add (add a local pkg to the install list), remove (add a localdb entry to the remove list), sync (add a sync package from the sync repos); and one resolve and one commit funtions. Benefits: -we can use the current code with few modifications (alpm_*_loadtarget are almost the same, keeping sync_prepare + my patches is ~enough, sync_commit is ~enough (add_commit and remove_commit would be helper functions)) -this would kill many duplicates in the code -the difference between -A/-U and -S would disappear: the pkgorigin would be different only (handled in commit) => resolving dependencies/conflicts would also work with -A/-U (on request) -more freedom (to front-end) Bye, ngaba ---------------------------------------------------- SZTE Egyetemi Könyvtár - http://www.bibl.u-szeged.hu This mail sent through IMP: http://horde.org/imp/
participants (3)
-
Dan McGee
-
Nagy Gabor
-
Xavier