IgnorePkg causes avoidable pacman errors

bji · 2008-12-27 09:27:56

When a package is added to IgnorePkg, it will not be updated by pacman. I expected then that any package which depends on the ignored package would also be ignored by pacman since its dependencies cannot be satisfied. However, pacman seems instead to issue an error, because it does not cull out the set of packages that cannot be updated due to being dependent on an update to a package that is in IgnorePkg, and as a result, encounters a situation where a package that it thinks you want it to upgrade, cannot be upgraded.

As an example, consider my current set of available package upgrades:

[root@lolita ~]# pacman -Qu
Checking for package upgrades... 

Targets (31): cairo-1.8.6-1  dbus-glib-0.78-1  firefox-3.0.5-1  gnutls-2.6.3-1  
              gtk2-2.14.6-1  hal-info-0.20081219-1  hdparm-9.3-1  
              hwdetect-2008.12-2  intel-dri-7.2-2  kernel26-2.6.27.10-1  
              klibc-udev-135-1  libdmx-1.0.2-2  libgsf-1.14.10-1  
              libpng-1.2.34-1  libtasn1-1.7-1  libxfont-1.3.4-1  
              libxml2-2.7.2-1  nss-3.12.2-1  pango-1.22.4-1  pycairo-1.8.0-1  
              smbclient-3.2.6-2  subversion-1.5.5-1  tar-1.20-3  tdb-3.2.6-2  
              ttf-dejavu-2.28-1  udev-135-1  xcb-util-0.3.2-1  
              xextproto-7.0.4-1  xkeyboard-config-1.4-2  xorg-font-utils-7.4-1  
              xulrunner-1.9.0.5-1  

Total Download Size:    0.00 MB
Total Installed Size:   287.64 MB

Now to demonstrate the problem, I'll add xulrunner to my IgnorePkg list. firefox-3.0.5-1 depends on xulrunner-1.9.0.5, so in this test case, firefox will no longer be upgradeable because I will have prevented one of the packages it depends on from being installed:

(in /etc/pacman.conf):

IgnorePkg = xulrunner

[root@lolita ~]# pacman -Qu
Checking for package upgrades... 
warning: xulrunner: ignoring package upgrade (1.9.0.4-1 => 1.9.0.5-1)

Targets (30): cairo-1.8.6-1  dbus-glib-0.78-1  firefox-3.0.5-1  gnutls-2.6.3-1  
              gtk2-2.14.6-1  hal-info-0.20081219-1  hdparm-9.3-1  
              hwdetect-2008.12-2  intel-dri-7.2-2  kernel26-2.6.27.10-1  
              klibc-udev-135-1  libdmx-1.0.2-2  libgsf-1.14.10-1  
              libpng-1.2.34-1  libtasn1-1.7-1  libxfont-1.3.4-1  
              libxml2-2.7.2-1  nss-3.12.2-1  pango-1.22.4-1  pycairo-1.8.0-1  
              smbclient-3.2.6-2  subversion-1.5.5-1  tar-1.20-3  tdb-3.2.6-2  
              ttf-dejavu-2.28-1  udev-135-1  xcb-util-0.3.2-1  
              xextproto-7.0.4-1  xkeyboard-config-1.4-2  xorg-font-utils-7.4-1  

Total Download Size:    0.00 MB
Total Installed Size:   228.42 MB

OK, pacman -Qu doesn't seem to realize that firefox-3.0.5 is not a target I could want to install since I have explicitly forbidden the installation of a package it depends on. What about trying the actual upgrade?

[root@lolita ~]# pacman -Su
:: Starting full system upgrade...
warning: xulrunner: ignoring package upgrade (1.9.0.4-1 => 1.9.0.5-1)
resolving dependencies...
:: firefox requires installing xulrunner from IgnorePkg/IgnoreGroup. Install anyway? [Y/n]

Well its nice that it has recognized the situation it's been put in with respect to firefox. I'll tell it no, that I don't want firefox installed.

:: firefox requires installing xulrunner from IgnorePkg/IgnoreGroup. Install anyway? [Y/n] n
error: cannot resolve "xulrunner=1.9.0.5", a dependency of "firefox"
error: failed to prepare transaction (could not satisfy dependencies)
:: firefox: requires xulrunner=1.9.0.5

OK here's where I think pacman should operate differently. I've just told it that I don't want to install firefox even though a new version is available, because I don't want an upgrade to a package that firefox depends on.

I think pacman should just remove firefox from its list of packages to install, and proceed with the rest. I only said 'no' to firefox, I didn't say 'no' to anything else. Why exit with error?

The actual package that I want to add to IgnorePkg is kernel26, because I use a custom build kernel (the kernel26-ice version with tuxonice support), and I don't want packages to upgrade which depend on kernel26 without first giving myself a chance to upgrade kernel26-ice to the newer version as well. I thought that if I just added kernel26 to my IgnorePkg, then that package, and any package which depends on it, would not be upgraded by pacman, which would be exactly the behavior I need. Instead, it looks like I just won't be able to upgrade at all without explicitly listing packages that depend on kernel26 as I encounter them, a tedious and manual process that I think pacman should just do automatically (perhaps with some confirmation) by culling out the updates that depend on my IgnorePkg packages before proposing the transaction.

Allan · 2008-12-27 09:38:16

Things like this get lost on the forums. File a bug report.

tomk · 2008-12-27 09:39:36

Post a feature request under the pacman project in the bugtracker, and/or join the pacman-dev mailing list and raise your concerns there. If you can provide a patch to amend pacman's functionality as you required, that would be good too.

Re your specific issue, though - if you don't use kernel26, why do you have packages that depend on it installed in the first place? Anything that depends on kernel26 is going to be an external module package e.g. nvidia, madwifi, etc, and they won't work with your custom kernel, as they are built against the stock kernel.

bji · 2008-12-27 09:40:21

Allan wrote:

Things like this get lost on the forums. File a bug report.

Sure, I'd be happy to - once I get some feedback from people who know better than me whether or not this actually is a bug, or if it's as designed, which is the purpose of my post ...

bji · 2008-12-27 09:54:36

tomk wrote:

Post a feature request under the pacman project in the bugtracker, and/or join the pacman-dev mailing list and raise your concerns there. If you can provide a patch to amend pacman's functionality as you required, that would be good too.
Re your specific issue, though - if you don't use kernel26, why do you have packages that depend on it installed in the first place? Anything that depends on kernel26 is going to be an external module package e.g. nvidia, madwifi, etc, and they won't work with your custom kernel, as they are built against the stock kernel.

Thanks, I will post a bug and post on the mailing list. I was not sure if this issue is something that has already been hashed out before and the behavior as it is was specifically chosen for reasons that I don't know about, but it sounds like you're saying that my point may be valid.

As to my specific issue, perhaps my approach has problems I did not realize; maybe you can enlighten me. I consider my kernel26-ice package to be what the stock kernel would have been had tuxonice been enabled in it (the .config I used for my kernel26-ice build is identical to that of the stock kernel, except for the parts where it adds tuxonice in). I keep the two packages installed in parallel and can choose in my grub menu which one to boot (I always boot the tuxonice version, but keep the stock kernel around just in case there is some unexpected problem with the tuxonice kernel). I had assumed that there were dependencies on the kernel that my -ice kernel satisifies 'just as well'; for example, if there is a package which depends on a kernel module in the stock kernel, the kernel I run provides the exact same module. So for all intents and purposes the kernel26-ice kernel is a runtime drop-in replacement for kernel26, and satisfies all dependencies in the same way.

I don't believe it would have been easy to take the stock kernel out due to all of the dependencies on the specific kernel26 package; and also, it's not easy to just switch every package that depends on kernel26 to depend on kernel26-ice instead. So I leave kernel26 there to satisfy the dependencies, but my kernel26-ice actually steps in at boot time as a runtime replacement for kernel26.

I don't want kernel26 to get upgraded, because some package may have a dependency which gets changed in the new kernel that my -ice kernel will not satisfy. So I'll upgrade my -ice kernel first to the new version, then allow pacman to update the stock kernel to the new version, and subsequently upgrade all packages which have a dependency on the kernel, which will once again be properly supported by my -ice kernel.

Does this make any sense? Is there a better way to replace the stock kernel than this, and still retain dependency checking and all the niceties of a package management system?

tomk · 2008-12-27 14:44:33

Anything you have installed which depends on kernel26 will only work with kernel26, and will fail when you run your ice kernel. As I said, kernel-dependant packages are always external, or out-of-tree, modules, so they are installed in /lib/modules/<kernel_version> - for the current stock kernel, that's /lib/modules/2.6.27-ARCH. Modules that need to work with your ice kernel have to be installed in /lib/modules/<your_ice_kernel_version> - I've no idea how you have named it, but it won't be the same as the above.

For example, if you have installed nvidia from the Arch extra repo, you have /lib/modules/2.6.27-ARCH/kernel/drivers/video/nvidia.ko. However, your ice kernel cannot see that path, so to get nvidia working with your ice kernel, you need /lib/modules/<your_ice_kernel_version>/kernel/drivers/video/nvidia.ko.

You are correct in your assumption that your ice kernel is effectively a drop-in replacement for kernel26, but you need to realise that if you want fully equivalent functionality from both kernels, you will need separate external module packages for each kernel. Taking the nvidia example again, that mean you need nvidia for kernel26, and nvidia-ice for kernel26-ice.

Hope this helps.

shining · 2008-12-27 18:38:54

bji wrote:

tomk wrote:
Post a feature request under the pacman project in the bugtracker, and/or join the pacman-dev mailing list and raise your concerns there. If you can provide a patch to amend pacman's functionality as you required, that would be good too.
Thanks, I will post a bug and post on the mailing list. I was not sure if this issue is something that has already been hashed out before and the behavior as it is was specifically chosen for reasons that I don't know about, but it sounds like you're saying that my point may be valid.

No need, it is already there :
http://bugs.archlinux.org/task/9395

We don't consider this as a bug, more a feature request : it is a new behavior that could be enabled by a new flag.
But we are not fully convinced we need this additional complexity.

bji · 2008-12-27 22:53:04

tomk wrote:

Anything you have installed which depends on kernel26 will only work with kernel26, and will fail when you run your ice kernel. As I said, kernel-dependant packages are always external, or out-of-tree, modules, so they are installed in /lib/modules/<kernel_version> - for the current stock kernel, that's /lib/modules/2.6.27-ARCH. Modules that need to work with your ice kernel have to be installed in /lib/modules/<your_ice_kernel_version> - I've no idea how you have named it, but it won't be the same as the above.
For example, if you have installed nvidia from the Arch extra repo, you have /lib/modules/2.6.27-ARCH/kernel/drivers/video/nvidia.ko. However, your ice kernel cannot see that path, so to get nvidia working with your ice kernel, you need /lib/modules/<your_ice_kernel_version>/kernel/drivers/video/nvidia.ko.
You are correct in your assumption that your ice kernel is effectively a drop-in replacement for kernel26, but you need to realise that if you want fully equivalent functionality from both kernels, you will need separate external module packages for each kernel. Taking the nvidia example again, that mean you need nvidia for kernel26, and nvidia-ice for kernel26-ice.
Hope this helps.

Thanks for the advice, very helpful. What is the best way to deal with this situation? I imagine that many people build custom kernels, how do others manage kernel dependencies in this case? What about for other programs - if you custom build a particular package with your own compiler flags or whatnot, do you simply replace the existing package with your own, and deal with pacman upgrades of that package after they happen by recompiling the newer version and re-replacing it? Or is there a better way?

In this particular case, I did have a few modules packages that I had to rebuild myself to match the -ice kernel. One was the pcc_acpi package, which provides support for some ACPI features of the Pansonic laptop I have installed Arch on. The other was the virtualbox-modules package, which provides a kernel module that VirtualBox needs to run. I renamed the package virtualbox-modules-ice so that it can exist in parallel with the stock virtualbox-modules package.

It seems like I should add the package correspnding to any package that I have custom build and replaced the existing package with, or custom built and installed as a "parallel" package as I have done with kerne26-ice and virtualbox-modules-ice to the IgnorePkg line of pacman.conf, to ensure that I get an opportunity to upgrade my custom versions at the same time that the stock versions are upgraded. Does that sound like a reasonable approach? In this case, the desired behavior of pacman that I have described in this thread would go a long way towards making upgrading the rest of the system easy while retaining my own custom packages.

bji · 2008-12-27 22:54:43

shining wrote:

We don't consider this as a bug, more a feature request : it is a new behavior that could be enabled by a new flag.
But we are not fully convinced we need this additional complexity.

Thanks for the pointer. Although I would not agree with the term 'additional complexity' here, because this feature could only serve to make managing packages with pacman easier and simpler for the end-user, not more complex. I get the feeling that calling a new feature 'added complexity' is the kiss of death in the Arch world, and I don't feel that it's really justified here. Thanks again for pointing me to the bug, I will add my thoughts to it.

kludge · 2008-12-28 06:44:03

I don't believe it would have been easy to take the stock kernel out due to all of the dependencies on the specific kernel26 package; and also, it's not easy to just switch every package that depends on kernel26 to depend on kernel26-ice instead. So I leave kernel26 there to satisfy the dependencies, but my kernel26-ice actually steps in at boot time as a runtime replacement for kernel26.

this probably won't work for parallel kernels because of the module paths, but PKGBUILDs do have the provides= variable. i've successfully used this, e.g., to provide a replacement to libdrm that wouldn't break upgrades. i'll probably be using it again momentarily for a local xorg-server-screw-hal package. then i should be able to add xorg-server to IgnorePkg and still get updates to pkgs that depend upon xorg-server. i haven't done it yet, but it worked for libdrm-mach and i think the theory's sound.

edit: come to think of it, this is better for providing alternatives than for parallel packages. however, if my local xorg-server package has the same name, it will at least provide me with a notification to bump the version, recomplie, reinstall and then pacman -Syu. hope this helps, and if it's useless, please forgive me burbling in your thread...

Last edited by kludge (2008-12-28 06:52:19)

bji · 2008-12-30 22:20:30

I have submitted a patched version of pacman to the AUR which fixes this issue. I am hoping to get my changes incorporated into the official pacman sources. The fixed package is at:

http://aur.archlinux.org/packages.php?ID=11182

bji · 2008-12-31 02:37:26

Hey all. Sorry, but my AUR package has been deleted because I should not have uploaded a replacement for a core package to AUR. If anyone is interested in trying my patch, please let me know; I can upload a new package to AUR with a new name, for testing purposes, if anyone wants to try it. But if no one is interested, I think I'll save myself the trouble for now, and concentrate on getting the patch (hopefully) accepted by the pacman dev team. Thanks.

rson451 · 2008-12-31 12:39:11

Just post a diff so those who wish to test it can patch it for themselves.

Allan · 2008-12-31 12:45:33

You can get the patch from the pacman-dev list.

bji · 2009-08-07 22:08:19

I'm happy to report that with the pacman 3.3.0 release, my changes to fix this behavior are now standard in pacman. The new behavior is as I described in my original post: pacman now gives you a prompt during upgrade to ignore updated packages that depend on ignored updated packages. In other words, all packages that depend on ignored packages are also treated as ignored, if you answer Yes to the prompt. This makes keeping your system up to date when you have ignored packages much easier.

It sure took a while for my January changes to make it into a pacman release but ... I'm happy they're finally there!

Arch Linux

#1 2008-12-27 09:27:56

IgnorePkg causes avoidable pacman errors

#2 2008-12-27 09:38:16

Re: IgnorePkg causes avoidable pacman errors

#3 2008-12-27 09:39:36

Re: IgnorePkg causes avoidable pacman errors

#4 2008-12-27 09:40:21

Re: IgnorePkg causes avoidable pacman errors

#5 2008-12-27 09:54:36

Re: IgnorePkg causes avoidable pacman errors

#6 2008-12-27 14:44:33

Re: IgnorePkg causes avoidable pacman errors

#7 2008-12-27 18:38:54

Re: IgnorePkg causes avoidable pacman errors

#8 2008-12-27 22:53:04

Re: IgnorePkg causes avoidable pacman errors

#9 2008-12-27 22:54:43

Re: IgnorePkg causes avoidable pacman errors

#10 2008-12-28 06:44:03

Re: IgnorePkg causes avoidable pacman errors

#11 2008-12-30 22:20:30

Re: IgnorePkg causes avoidable pacman errors

#12 2008-12-31 02:37:26

Re: IgnorePkg causes avoidable pacman errors

#13 2008-12-31 12:39:11

Re: IgnorePkg causes avoidable pacman errors

#14 2008-12-31 12:45:33

Re: IgnorePkg causes avoidable pacman errors

#15 2009-08-07 22:08:19

Re: IgnorePkg causes avoidable pacman errors

Board footer