Re: [pacman-dev] [arch-general] Package group xorg-video-drivers: intel conflict
On Sat, Dec 08, 2007 at 10:16:19PM +0100, Michael Towers wrote:
Aaron Griffin wrote:
On Dec 8, 2007 11:04 AM, Michael Towers <gradgrind@online.de> wrote:
Since the addition of xf86-video-intel it has become impossible to install the xorg-video-drivers group via the group name (because of the conflict with xf86-video-i810).
I guess there is no guideline outlawing this - I suppose something like this could, theoretically, happen more often. But it is a bit annoying when doing installations which are supposed to run on various machines.
I don't want to make a request or anything here - I don't know what I could ask for. I just thought I'd point it out.
Hmmm, I'd say in cases like this we pick one that we prefer, and keep that in the group. /me shrugs
Maybe FR that regarding these two drivers and we can see how Alex feels about it?
Why can't we do pacman -S xorg-video-drivers --ignore xf86-video-i810 ? Though, it's probably a bad idea to put conflicting packages in the same group in the first place, but still.. Suppose "target" is part of "group", and target is in IgnorePkg, it might make sense that : * pacman -S group doesn't install target * pacman -S target installs target (because explictly asked) Anyway, here is a sample session, how I like them (it may have been mentioned already, but I don't remember where) :
sudo pacman -S xorg-video-drivers :: group xorg-video-drivers: xf86-video-intel :: Install whole content? [Y/n] :: group xorg-video-drivers: xf86-video-amd xf86-video-apm xf86-video-ark xf86-video-ati xf86-video-chips xf86-video-cirrus xf86-video-dummy xf86-video-fbdev xf86-video-glint xf86-video-i128 xf86-video-i740 xf86-video-i810 xf86-video-imstt xf86-video-intel xf86-video-mga xf86-video-neomagic xf86-video-nv xf86-video-radeonhd xf86-video-rendition xf86-video-s3 xf86-video-s3virge xf86-video-savage xf86-video-siliconmotion xf86-video-sis xf86-video-sisusb xf86-video-tdfx xf86-video-trident xf86-video-tseng xf86-video-unichrome xf86-video-v4l xf86-video-vesa xf86-video-vga xf86-video-via xf86-video-vmware xf86-video-voodoo :: Install whole content? [Y/n] warning: xf86-video-intel-2.1.1-3 is up to date -- reinstalling warning: xf86-video-vesa-1.3.0-5 is up to date -- reinstalling resolving dependencies... looking for inter-conflicts... error: unresolvable package conflicts detected error: failed to prepare transaction (conflicting dependencies) :: xf86-video-intel: conflicts with xf86-video-i810
Ok, xf86-video-i810 is not a conflict, so we won't ask the whole content next time.
sudo pacman -S xorg-video-drivers :: group xorg-video-drivers: xf86-video-intel :: Install whole content? [Y/n] :: group xorg-video-drivers: xf86-video-amd xf86-video-apm xf86-video-ark xf86-video-ati xf86-video-chips xf86-video-cirrus xf86-video-dummy xf86-video-fbdev xf86-video-glint xf86-video-i128 xf86-video-i740 xf86-video-i810 xf86-video-imstt xf86-video-intel xf86-video-mga xf86-video-neomagic xf86-video-nv xf86-video-radeonhd xf86-video-rendition xf86-video-s3 xf86-video-s3virge xf86-video-savage xf86-video-siliconmotion xf86-video-sis xf86-video-sisusb xf86-video-tdfx xf86-video-trident xf86-video-tseng xf86-video-unichrome xf86-video-v4l xf86-video-vesa xf86-video-vga xf86-video-via xf86-video-vmware xf86-video-voodoo :: Install whole content? [Y/n] n :: Install xf86-video-amd from group xorg-video-drivers? [Y/n] :: Install xf86-video-apm from group xorg-video-drivers? [Y/n] :: Install xf86-video-ark from group xorg-video-drivers? [Y/n] :: Install xf86-video-ati from group xorg-video-drivers? [Y/n] :: Install xf86-video-chips from group xorg-video-drivers? [Y/n] :: Install xf86-video-cirrus from group xorg-video-drivers? [Y/n] :: Install xf86-video-dummy from group xorg-video-drivers? [Y/n] :: Install xf86-video-fbdev from group xorg-video-drivers? [Y/n] :: Install xf86-video-glint from group xorg-video-drivers? [Y/n] :: Install xf86-video-i128 from group xorg-video-drivers? [Y/n] :: Install xf86-video-i740 from group xorg-video-drivers? [Y/n] :: Install xf86-video-i810 from group xorg-video-drivers? [Y/n] n :: Install xf86-video-imstt from group xorg-video-drivers? [Y/n] :: Install xf86-video-intel from group xorg-video-drivers? [Y/n] :: Install xf86-video-mga from group xorg-video-drivers? [Y/n] :: Install xf86-video-neomagic from group xorg-video-drivers? [Y/n] :: Install xf86-video-nv from group xorg-video-drivers? [Y/n] :: Install xf86-video-radeonhd from group xorg-video-drivers? [Y/n] :: Install xf86-video-rendition from group xorg-video-drivers? [Y/n] :: Install xf86-video-s3 from group xorg-video-drivers? [Y/n] :: Install xf86-video-s3virge from group xorg-video-drivers? [Y/n] :: Install xf86-video-savage from group xorg-video-drivers? [Y/n] :: Install xf86-video-siliconmotion from group xorg-video-drivers? [Y/n] :: Install xf86-video-sis from group xorg-video-drivers? [Y/n] :: Install xf86-video-sisusb from group xorg-video-drivers? [Y/n] :: Install xf86-video-tdfx from group xorg-video-drivers? [Y/n] :: Install xf86-video-trident from group xorg-video-drivers? [Y/n] :: Install xf86-video-tseng from group xorg-video-drivers? [Y/n] :: Install xf86-video-unichrome from group xorg-video-drivers? [Y/n] :: Install xf86-video-v4l from group xorg-video-drivers? [Y/n] :: Install xf86-video-vesa from group xorg-video-drivers? [Y/n] :: Install xf86-video-vga from group xorg-video-drivers? [Y/n] :: Install xf86-video-via from group xorg-video-drivers? [Y/n] :: Install xf86-video-vmware from group xorg-video-drivers? [Y/n] :: Install xf86-video-voodoo from group xorg-video-drivers? [Y/n]
warning: xf86-video-intel-2.1.1-3 is up to date -- reinstalling warning: xf86-video-vesa-1.3.0-5 is up to date -- reinstalling resolving dependencies... looking for inter-conflicts... error: unresolvable package conflicts detected error: failed to prepare transaction (conflicting dependencies) :: xf86-video-unichrome: conflicts with xf86-video-via Oh no, I have to start everything again. Seriously, how practical is that? Personally, I never used it, and I don't see the point of this interactivity. I just do pacman -S group, I have a look at all the targets it wants to pull. And then, either I accept, or I refuse, and I run pacman -S again by picking the few targets I want manually. But if instead of only picking a few targets, you just want to exclude a few ones, then IgnorePkg should probably apply here. What do you think? There might be some important and common use cases I'm forgetting, which is why I bring this up here for discussion.
Oh no, I have to start everything again. Seriously, how practical is that? Personally, I never used it, and I don't see the point of this interactivity. I just do pacman -S group, I have a look at all the targets it wants to pull. And then, either I accept, or I refuse, and I run pacman -S again by picking the few targets I want manually. But if instead of only picking a few targets, you just want to exclude a few ones, then IgnorePkg should probably apply here.
What do you think? There might be some important and common use cases I'm forgetting, which is why I bring this up here for discussion.
You are right, this is not practical. However, currently group adding is handled in front-end (which is right imho), so the front-end decides which packages it will add, and it does a 'pacman -S selected_packages'. Currently "pacman -S foo" ignores[;-)] --ignore foo (note: IgnorePkg can also be defined in pacman.conf) to avoid needless "Do you want to install to foo?" <- in this explicit case user _wants_ to install foo. So you may want to 1. change this behavior or 2. do IgnorePkg check in front-end or 3. move group adding to libalpm or 4. or implement new sync_addtarget (or add ignorepkg parameter to the current one) Well, I don't really like none of them (but if you have no other ideas, I would prefer (add parameter...) from 4.) Bye ---------------------------------------------------- SZTE Egyetemi Könyvtár - http://www.bibl.u-szeged.hu This mail sent through IMP: http://horde.org/imp/
On Dec 10, 2007 9:08 AM, Nagy Gabor <ngaba@bibl.u-szeged.hu> wrote:
Oh no, I have to start everything again. Seriously, how practical is that? Personally, I never used it, and I don't see the point of this interactivity. I just do pacman -S group, I have a look at all the targets it wants to pull. And then, either I accept, or I refuse, and I run pacman -S again by picking the few targets I want manually. But if instead of only picking a few targets, you just want to exclude a few ones, then IgnorePkg should probably apply here.
What do you think? There might be some important and common use cases I'm forgetting, which is why I bring this up here for discussion.
You are right, this is not practical. However, currently group adding is handled in front-end (which is right imho), so the front-end decides which packages it will add, and it does a 'pacman -S selected_packages'. Currently "pacman -S foo" ignores[;-)] --ignore foo (note: IgnorePkg can also be defined in pacman.conf) to avoid needless "Do you want to install to foo?" <- in this explicit case user _wants_ to install foo. So you may want to 1. change this behavior or 2. do IgnorePkg check in front-end or 3. move group adding to libalpm or 4. or implement new sync_addtarget (or add ignorepkg parameter to the current one)
Well, I don't really like none of them (but if you have no other ideas, I would prefer (add parameter...) from 4.)
Hmm, it almost makes sense to do something of the sort: int alpm_add_target(pmtrans_t *trans, const char *pkgname) { ... if(is_ignored(pkgname)) { return PM_ERR_PKG_IGNORED; } ... } if(alpm_add_target(trans, "xorg-video-something") == PM_ERR_PKG_IGNORED) { puts("omg the package was ignored, panic panic!"); } At least, that is how I'd think it through.
On Mon, Dec 10, 2007 at 10:47:00AM -0600, Aaron Griffin wrote:
Hmm, it almost makes sense to do something of the sort:
int alpm_add_target(pmtrans_t *trans, const char *pkgname) { ... if(is_ignored(pkgname)) { return PM_ERR_PKG_IGNORED; } ... }
if(alpm_add_target(trans, "xorg-video-something") == PM_ERR_PKG_IGNORED) { puts("omg the package was ignored, panic panic!"); }
At least, that is how I'd think it through.
sync_addtarget had some sort of Ignore support before, but I didn't find it consistent : http://www.archlinux.org/pipermail/pacman-dev/2007-November/010112.html So I removed it in 8f824e70b. But clearly, I didn't take the group case in consideration. I dislike that we can't make the distinction between a group and a simple target here, but well.. Probably just having sync_addtarget always ignore the packages would be easier, like in what you are suggesting.
On Mon, Dec 10, 2007 at 07:13:57PM +0100, Xavier wrote:
On Mon, Dec 10, 2007 at 10:47:00AM -0600, Aaron Griffin wrote:
Hmm, it almost makes sense to do something of the sort:
int alpm_add_target(pmtrans_t *trans, const char *pkgname) { ... if(is_ignored(pkgname)) { return PM_ERR_PKG_IGNORED; } ... }
if(alpm_add_target(trans, "xorg-video-something") == PM_ERR_PKG_IGNORED) { puts("omg the package was ignored, panic panic!"); }
At least, that is how I'd think it through.
sync_addtarget had some sort of Ignore support before, but I didn't find it consistent : http://www.archlinux.org/pipermail/pacman-dev/2007-November/010112.html So I removed it in 8f824e70b. But clearly, I didn't take the group case in consideration. I dislike that we can't make the distinction between a group and a simple target here, but well.. Probably just having sync_addtarget always ignore the packages would be easier, like in what you are suggesting.
How about this patch? Xavier, this is different from what you removed in 8f824e70b because it is now sees if 'spkg' is ignored, not 'local'. Some examples: $ sudo pacman -S gnome-extra --ignore evince :: group gnome-extra (including ignored packages): bug-buddy dasher eog evince file-roller gcalctool gconf-editor gdm gedit gnome-audio gnome-games gnome-mag gnome-netstatus gnome-nettool gnome-power-manager gnome-python-desktop gnome-system-monitor gnome-terminal gnome-utils gnome-volume-manager gok gucharmap nautilus-cd-burner orca seahorse sound-juicer tomboy totem vino zenity :: Install whole content? [Y/n] :: evince is in IgnorePkg/IgnoreGroup. Install anyway? [Y/n] n resolving dependencies... looking for inter-conflicts... Targets: (no evince or dependencies here) Total Download Size: 77.89 MB Proceed with installation? [Y/n] n $ sudo pacman -S arts --ignore arts # arts is not installed :: arts is in IgnorePkg/IgnoreGroup. Install anyway? [Y/n] resolving dependencies... looking for inter-conflicts... Targets: kde-common-3.5.8-1 [0.11 MB] arts-1.5.8-1 [1.35 MB] Total Download Size: 1.47 MB Proceed with installation? [Y/n] n $ sudo pacman -S bash --ignore bash # bash is installed :: bash is in IgnorePkg/IgnoreGroup. Install anyway? [Y/n] warning: bash-3.2.025-4 is up to date -- reinstalling resolving dependencies... looking for inter-conflicts... Targets: bash-3.2.025-4 [0.40 MB] Total Download Size: 0.40 MB Proceed with installation? [Y/n] n From: Nathan Jones <nathanj@insightbb.com> Date: Sat, 15 Dec 2007 10:48:00 -0500 Subject: [PATCH] Check ignored packages in _alpm_sync_addtarget(). This will allow someone to install a group but ignore individual packages inside the group. Signed-off-by: Nathan Jones <nathanj@insightbb.com> --- lib/libalpm/sync.c | 8 ++++++++ src/pacman/sync.c | 2 +- 2 files changed, 9 insertions(+), 1 deletions(-) diff --git a/lib/libalpm/sync.c b/lib/libalpm/sync.c index 065340c..7128fea 100644 --- a/lib/libalpm/sync.c +++ b/lib/libalpm/sync.c @@ -346,6 +346,14 @@ int _alpm_sync_addtarget(pmtrans_t *trans, pmdb_t *db_local, alpm_list_t *dbs_sy RET_ERR(PM_ERR_PKG_NOT_FOUND, -1); } + if(_alpm_pkg_should_ignore(spkg)) { + int resp; + QUESTION(trans, PM_TRANS_CONV_INSTALL_IGNOREPKG, spkg, NULL, NULL, &resp); + if (!resp) { + return(0); + } + } + local = _alpm_db_get_pkgfromcache(db_local, alpm_pkg_get_name(spkg)); if(local) { if(alpm_pkg_compare_versions(local, spkg) == 0) { diff --git a/src/pacman/sync.c b/src/pacman/sync.c index df102af..f6f82be 100644 --- a/src/pacman/sync.c +++ b/src/pacman/sync.c @@ -584,7 +584,7 @@ static int sync_trans(alpm_list_t *targets, int sync_only) alpm_list_t *k; found++; - printf(_(":: group %s:\n"), targ); + printf(_(":: group %s (including ignored packages):\n"), targ); /* remove dupe entries in case a package exists in multiple repos */ const alpm_list_t *grppkgs = alpm_grp_get_pkgs(grp); alpm_list_t *pkgs = alpm_list_remove_dupes(grppkgs); -- 1.5.3.7
On Sat, Dec 15, 2007 at 11:01:52AM -0500, Nathan Jones wrote:
How about this patch? Xavier, this is different from what you removed in 8f824e70b because it is now sees if 'spkg' is ignored, not 'local'. Some examples:
From: Nathan Jones <nathanj@insightbb.com> Date: Sat, 15 Dec 2007 10:48:00 -0500 Subject: [PATCH] Check ignored packages in _alpm_sync_addtarget().
This will allow someone to install a group but ignore individual packages inside the group.
Signed-off-by: Nathan Jones <nathanj@insightbb.com> --- lib/libalpm/sync.c | 8 ++++++++ src/pacman/sync.c | 2 +- 2 files changed, 9 insertions(+), 1 deletions(-)
diff --git a/lib/libalpm/sync.c b/lib/libalpm/sync.c index 065340c..7128fea 100644 --- a/lib/libalpm/sync.c +++ b/lib/libalpm/sync.c @@ -346,6 +346,14 @@ int _alpm_sync_addtarget(pmtrans_t *trans, pmdb_t *db_local, alpm_list_t *dbs_sy RET_ERR(PM_ERR_PKG_NOT_FOUND, -1); }
+ if(_alpm_pkg_should_ignore(spkg)) { + int resp; + QUESTION(trans, PM_TRANS_CONV_INSTALL_IGNOREPKG, spkg, NULL, NULL, &resp); + if (!resp) { + return(0); + } + } + local = _alpm_db_get_pkgfromcache(db_local, alpm_pkg_get_name(spkg)); if(local) { if(alpm_pkg_compare_versions(local, spkg) == 0) {
Thanks, it's perfect, that's kinda what I had in mind as a quick fix before the 3.1 release (but I'm a little busy these days :p).
diff --git a/src/pacman/sync.c b/src/pacman/sync.c index df102af..f6f82be 100644 --- a/src/pacman/sync.c +++ b/src/pacman/sync.c @@ -584,7 +584,7 @@ static int sync_trans(alpm_list_t *targets, int sync_only) alpm_list_t *k;
found++; - printf(_(":: group %s:\n"), targ); + printf(_(":: group %s (including ignored packages):\n"), targ); /* remove dupe entries in case a package exists in multiple repos */ const alpm_list_t *grppkgs = alpm_grp_get_pkgs(grp); alpm_list_t *pkgs = alpm_list_remove_dupes(grppkgs); -- 1.5.3.7
Well, not sure this is necessary, because the packages aren't automatically ignored, a question is asked and the user can choose. But why not, it makes it clearer than the group handling happens first, in the frontend, and the ignore handling happens only later, in the backend.
On Mon, Dec 10, 2007 at 04:08:59PM +0100, Nagy Gabor wrote:
Oh no, I have to start everything again. Seriously, how practical is that? Personally, I never used it, and I don't see the point of this interactivity. I just do pacman -S group, I have a look at all the targets it wants to pull. And then, either I accept, or I refuse, and I run pacman -S again by picking the few targets I want manually. But if instead of only picking a few targets, you just want to exclude a few ones, then IgnorePkg should probably apply here.
What do you think? There might be some important and common use cases I'm forgetting, which is why I bring this up here for discussion.
You are right, this is not practical. However, currently group adding is handled in front-end (which is right imho), so the front-end decides which packages it will add, and it does a 'pacman -S selected_packages'. Currently "pacman -S foo" ignores[;-)] --ignore foo (note: IgnorePkg can also be defined in pacman.conf) to avoid needless "Do you want to install to foo?" <- in this explicit case user _wants_ to install foo. So you may want to 1. change this behavior or
Maybe I'll propose a quick patch for this.
2. do IgnorePkg check in front-end or
I don't like this.
3. move group adding to libalpm or
I thought that would be a better solution, but probably a bigger change than 1.
4. or implement new sync_addtarget (or add ignorepkg parameter to the current one)
Not sure what you mean exactly here.
participants (4)
-
Aaron Griffin
-
Nagy Gabor
-
Nathan Jones
-
Xavier