[pacman-dev] [GIT] pacman branch, master now at v3.0.0-378-gb250195
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 b2501950c7fca0b771fc79054d9592ea79753749 (commit)
via b15a5194d1a8485a2769560e49e6ff03e1862533 (commit)
via 53fc745aedc0a6d24abbc8bce6ca0b30c2179e5f (commit)
via 678983d2623d7ed700a70634089eef1c9f0b9b21 (commit)
via 9cceb3d9c4d4b0975781a4d48eabfdd29026453e (commit)
via 39871375051856f9248d651005ab62e2a309d6ea (commit)
via 461bc9e6ce8afee23b6402b4af65aa29b7268c35 (commit)
via 824b7fd27b490e599025b38e629e53921df5883d (commit)
from b3a1619457fa6424570c90c0eaacbbf39fd9662c (commit)
- Log -----------------------------------------------------------------
commit b2501950c7fca0b771fc79054d9592ea79753749
Author: Dan McGee
sync400 : Install package with dep that conflicts with older version of package
This should prove the PS of http://www.archlinux.org/pipermail/pacman-dev/2007-August/009078.html Bye, ngaba ---------------------------------------------------- SZTE Egyetemi Könyvtár - http://www.bibl.u-szeged.hu This mail sent through IMP: http://horde.org/imp/
sync400 : Install package with dep that conflicts with older version
of
package This should prove the PS of http://www.archlinux.org/pipermail/pacman-dev/2007-August/009078.html Bye, ngaba This may not prove that, because the old version of pkg2 is installed; but as I see, in these case the reason field is not copied.
I'm suggest to work out a %REASON% policy, because I don't like the current method: -A/U copies the old reason field, if the old package is installed... OK, but the package may become orphan, so we can say, the reason is the _original_ reason; if the package is not installed, we get "explicitly installed" reason; fine. -however, -S seems buggy: it owerwrites the old reason iff the new reason is depend; so [1] if you have a pkg with depend reason, -S pkg will NOT overwrite the reason to explicit (here -S is an ~upgrade). [2] And if you have an explicitly installed pkg2, and "-S pkg1" also upgrades pkg2 (since pkg1 needs a newer version), the reason of pkg2 will be overwritten to depend (I don't like this.). Replace makes things even worse... So we should define and document the rules, then implement it;-) My suggestion: -A/U OK, user can use --asdeps, if he want to change the reason (--asexplicit is also needed IMHO) -S: the reason field should be kept iff the oldpkg is exists -change reason of localpkg switch can also be useful: this would let user change the depend reason to explicit (see [1]) Bye, ngaba A bit off: So I prefer "original reason" way, which can be changed by the user later. Only explicit packages are important to the user, all others are needed to satisfy deps of explicit packages. So I prefer using the important word instead of reason (HoldPkgs are the most important packages.) So I'd prefer important = 0 <=> depend && !HoldPkg important = 1 <=> explicit && !HoldPkg important = 2 <=> HoldPkg; so I think HoldPkg should be stored in local db; and in sync db ---------------------------------------------------- SZTE Egyetemi Könyvtár - http://www.bibl.u-szeged.hu This mail sent through IMP: http://horde.org/imp/
On Fri, Sep 07, 2007 at 06:27:34PM +0200, Nagy Gabor wrote:
I'm suggest to work out a %REASON% policy, because I don't like the current method: -A/U copies the old reason field, if the old package is installed... OK, but the package may become orphan, so we can say, the reason is the _original_ reason; if the package is not installed, we get "explicitly installed" reason; fine. -however, -S seems buggy: it owerwrites the old reason iff the new reason is depend; so [1] if you have a pkg with depend reason, -S pkg will NOT overwrite the reason to explicit (here -S is an ~upgrade). [2] And if you have an explicitly installed pkg2, and "-S pkg1" also upgrades pkg2 (since pkg1 needs a newer version), the reason of pkg2 will be overwritten to depend (I don't like this.). Replace makes things even worse... So we should define and document the rules, then implement it;-)
My suggestion: -A/U OK, user can use --asdeps, if he want to change the reason (--asexplicit is also needed IMHO) -S: the reason field should be kept iff the oldpkg is exists -change reason of localpkg switch can also be useful: this would let user change the depend reason to explicit (see [1])
I just noticed [1] yesterday, as someone on IRC wanted to mark a few packages as explictly installed (the dependencies of the xorg meta package, which was removed). So indeed, the only way to mark these as explicitly installed using pacman was to remove them, then install them again.. It might be a good idea to have an --asexplicit flag for this case.
A bit off: So I prefer "original reason" way, which can be changed by the user later. Only explicit packages are important to the user, all others are needed to satisfy deps of explicit packages. So I prefer using the important word instead of reason (HoldPkgs are the most important packages.) So I'd prefer important = 0 <=> depend && !HoldPkg important = 1 <=> explicit && !HoldPkg important = 2 <=> HoldPkg; so I think HoldPkg should be stored in local db; and in sync db
Now I am afraid I lost you, I am not sure how this would be useful.
A bit off: So I prefer "original reason" way, which can be changed by the user later. Only explicit packages are important to the user, all others are needed to satisfy deps of explicit packages. So I prefer using the important word instead of reason (HoldPkgs are the most important packages.) So I'd prefer important = 0 <=> depend && !HoldPkg important = 1 <=> explicit && !HoldPkg important = 2 <=> HoldPkg; so I think HoldPkg should be stored in local db; and in sync db
Now I am afraid I lost you, I am not sure how this would be useful.
Well, this is not so important. 1. I tried to explain why I prefer the way described above (with no success :-P), I wanted to explain my "concept". So explicitly installed package means (for me) that user need this package, because he installed by hand (he mentioned in the target list); dependency package means, that pacman installed that "behind" the user, so it is needed to satisfy the dependencies of explicitly installed packages only, so they are not so important (they can be removed, as no longer needed by other packages). We need to decide that a package is explicit or not when it first appears in local db, and we keep this property during upgrades (I derived this rule from the current behaviour of -U; someone may prefer the following: when we mention the package in the target list in case of -S, -U then that means that user really need that package, so we can change the reason to explicit.) 2. I don't like the current HoldPkg implementation, this should be totally handled by libalpm IMHO. HoldPkg means (for me) that the package is really important; IMHO this should be recorded to localdb and to syncdb (e.g. current/glibc should be flagged as HoldPkg). So we may add HoldPkg property to reason (important) field to unify, but if you want to keep the current reason field, you may add a new HOLDPKG entry... (If user could change the reason field then he could also "set" HoldPkg "flag"; orphan remove ignores HoldPkg and explicitly installed packages, so it removes the unneeded (reason/important == 0) ones only; if a package is holdpkg then its reason==explicit/depend is not important...) Bye, ngaba ---------------------------------------------------- SZTE Egyetemi Könyvtár - http://www.bibl.u-szeged.hu This mail sent through IMP: http://horde.org/imp/
-A/U OK, user can use --asdeps, ... By the way, please keep bash-completion up-to-date. 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