[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 <dan@archlinux.org> Date: Sun Sep 23 21:19:06 2007 -0500 Allow a normal 'make' to compile without asciidoc installed If we don't have asciidoc installed or enabled, we should still have a successful make. However, we want to ensure 'make dist' fails without asciidoc. This commit should ensure this. Signed-off-by: Dan McGee <dan@archlinux.org> commit 843d368ef60a74719dfc74a27de3fe3ef441951f Author: Dan McGee <dan@archlinux.org> Date: Sun Sep 23 14:43:03 2007 -0500 libalpm/add.c: fix backup array issue As seen with the recent upgrade of pacman and the removal of the pacman.d/current mirrorlist, files that were formerly in the backup array get deleted upon their removal, which could be dangerous. Instead, we should use the combined backup array of the old and new package. This fix should address this issue in a relatively straightforward way. In addition, old files should be moved to pacsave locations as expected. Signed-off-by: Dan McGee <dan@archlinux.org> commit 105fd40a4a9b221df0186e7500fe491b3b96d823 Author: Chantry Xavier <shiningxc@gmail.com> Date: Sun Sep 23 17:07:13 2007 +0200 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 <shiningxc@gmail.com> commit 6898bb0f9742e078f2c45609cf00d43438a14843 Author: Chantry Xavier <shiningxc@gmail.com> Date: Sun Sep 23 16:53:05 2007 +0200 Add two pactests with broken requiredby, and two about pacsave handling. remove048 is the case mentioned there (fails in 3.0 but works in 3.1) : http://www.archlinux.org/pipermail/pacman-dev/2007-September/009294.html It's the same as remove046 with -R instead of -Rc. sync060 is a case reported this morning on IRC : a pacman -Su wanted to replace gensplashutils by gensplash, but pacman said gensplashutils was required by initscripts-gensplash, while initscripts-gensplash was not even installed. This is also fixed in the current 3.1 code though. upgrade02{4,5} are the backup handling problem I described there : http://www.archlinux.org/pipermail/pacman-dev/2007-September/009376.html Signed-off-by: Chantry Xavier <shiningxc@gmail.com> commit 8acb6d24af81d57ed87339aaf3472bda28b3a38d Author: Dan McGee <dan@archlinux.org> Date: Sun Sep 23 15:44:40 2007 -0500 libalpm/remove.c: fix up arguments to unlink_file Move the progressbar code out of unlink_file so we can pass half the args. Signed-off-by: Dan McGee <dan@archlinux.org> commit d3c80030201b555efba2f31811cff627a3fdeaf8 Author: Dan McGee <dan@archlinux.org> Date: Sun Sep 23 12:20:48 2007 -0500 alpm: removed unused strtoupper wrapper, remove installeddate on parse_descfile installdate should never be present in a package descfile, so get rid of it. With the last commit, we also don't need the util strtoupper function. Signed-off-by: Dan McGee <dan@archlinux.org> commit 443950b7e9c40493a184d55caaa71c2b4daa3ffd Author: Chantry Xavier <shiningxc@gmail.com> Date: Sun Sep 23 19:01:37 2007 +0200 libalpm/package.c : fix for FS#8081, case sensitive comparisons in parse_descfile. This fix FS#8081. The tr_TR locale has known issue with case insensitive comparisons, mostly because upper(i) != I. So the .PKGINFO files generated by makepkg MUST contain all keywords in lowercases now. This was already done, but was not mandatory. Signed-off-by: Chantry Xavier <shiningxc@gmail.com> commit f9b7c67d24210dc4b2c77b751948e0f17f80583f Author: Chantry Xavier <shiningxc@gmail.com> Date: Tue Sep 18 20:46:41 2007 +0200 libalpm/add.c : fix backup handling (2) The mistake fixed in commit 26441cf65ca10d4bf218203df5db5e8a7270787b was actually done at two places. This fix the second one. Also remove one unnecessary newline introduced by commit d34b2c4ed84bc40f4a895846785481fad88116a2 Signed-off-by: Chantry Xavier <shiningxc@gmail.com> commit 1860ab898086096ef0d9aad66e29f86cbf271423 Author: Dan McGee <dan@archlinux.org> Date: Tue Sep 18 13:40:19 2007 -0500 Update NEWS, -S testing/qt example, and mirrorlist change Signed-off-by: Dan McGee <dan@archlinux.org> ----------------------------------------------------------------------- Diffstat: NEWS | 14 ++++-- doc/Makefile.am | 9 ++++ doc/pacman.8.txt | 2 +- etc/pacman.d/mirrorlist.in | 2 +- lib/libalpm/add.c | 22 ++++++--- lib/libalpm/package.c | 33 ++++++------- lib/libalpm/remove.c | 62 +++++++++++------------- lib/libalpm/util.c | 13 ----- lib/libalpm/util.h | 1 - pactest/tests/remove048.py | 10 ++++ pactest/tests/sync044.py | 20 ++++++++ pactest/tests/sync060.py | 15 ++++++ pactest/tests/upgrade010.py | 1 + pactest/tests/upgrade020.py | 1 + pactest/tests/upgrade021.py | 1 + pactest/tests/upgrade022.py | 1 + pactest/tests/upgrade023.py | 1 + pactest/tests/upgrade024.py | 15 ++++++ pactest/tests/{upgrade021.py => upgrade025.py} | 6 +- 19 files changed, 146 insertions(+), 83 deletions(-) hooks/update --- Git Source Code Management System hooks/update refs/heads/master \ 7325ebbc22091c698fd19140b7ed6986024ec6e8 \ 012f7939784358b02726c169543aa99436439335
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 <shiningxc@gmail.com>
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