[paludis-dev] [Paludis] #1161: inexplicable self-blocking depend atoms in installed-repository

Paludis trac at pioto.org
Fri May 13 09:14:57 UTC 2011

#1161: inexplicable self-blocking depend atoms in installed-repository
 Reporter:  christian.    |         Owner:
     Type:  defect        |        Status:  new
 Priority:  Sometime      |     Milestone:
Component:  clients/cave  |       Version:  0.60.4
 Keywords:                |    Blocked By:
 Blocking:                |  Distribution:  Gentoo
 When trying to resolve world or other packages (like lafilefixer) I get an
 error with sys-fs/cryptsetup-1.1.3-r3 and app-crypt/gnupg-2.0.17 each
 blocking itself:

 $ sudo cave resolve lafilefixer
 Done: 3183 steps


 I encountered the following errors:

 !   app-crypt/gnupg
     Reasons: !app-crypt/gnupg from app-crypt/gnupg, app-crypt/gpgme, kde-
     Unsuitable candidates:


 !   sys-fs/cryptsetup
     Reasons: !<sys-fs/cryptsetup-1.1.2 from sys-fs/lvm2, !sys-
 fs/cryptsetup from sys-fs/cryptsetup, sys-apps/hal
     Unsuitable candidates:


 I try to give a complete descriptions of my actions that led to this
 problem and my findings so far:

 All began with a problem when resolving world. Some new versions of dev-
 libs/popt and dev-libs/libgpg-error were required by some packages to be
 updated, but older versions of those two were required by already
 installed packages. To resolve the version conflict I added

 dev-libs/popt static-libs
 dev-libs/libgpg-error static-libs

 to my USE flags. One reason for that working was that sys-
 fs/cryptsetup-1.1.3-r1 depends like this

         !dynamic? (
                 || ( >=dev-libs/libgpg-error-1.10[static-libs] <dev-libs
 /libgpg-error-1.10 )
                 || ( >=dev-libs/popt-1.16-r1[static-libs] <dev-
 libs/popt-1.16-r1 )

 Then I did

 $ sudo cave resolve libgpg-error --reinstall-dependents-of libgpg-error
 --resume-file libgpg-error -1
 $ sudo cave resolve -1 popt --reinstall-dependents-of popt --resume-file

 to apply the new set USE flags.

 After that I did something like this (Don't remember if that was the full
 command. I think I added "-W sys-kernel/gentoo-soures" because of an
 unrelated issue.)

 $ sudo cave resolve world -c --resume-file world.cave --purge '*/*'
 --permit-downgrade 'dev-perl/PlRPC'

 Cave began to install the new packages but stopped at some package way in
 because of a problem with linking some library. Because I thought it was
 lafilefixer related I did this:

 $ sudo cave resolve lafilefixer

 which resulted the aforementioned self-blocking.

 I have pinpointed the problem to

 $ cat /vr/db/pkg/sys-fs/cryptsetup-1.1.3-r3/DEPEND

 >=sys-fs/lvm2-2.02.64 >=dev-libs/libgcrypt-1.1.42 >=dev-libs/libgpg-
 error-1.0-r1 >=dev-libs/popt-1.7
 >=sys-fs/udev-124 || ( >=sys-libs/e2fsprogs-libs-1.41 <sys-
 fs/e2fsprogs-1.41 ) selinux? (
 sys-libs/libselinux ) !sys-fs/cryptsetup !dynamic? ( || ( >=dev-libs
 <dev-libs/libgpg-error-1.10 ) || ( >=dev-libs/popt-1.16-r1[static-libs]
 <dev-libs/popt-1.16-r1 )
 dev-libs/libgcrypt[static-libs] )

 $ cat /var/db/pkg/app-crypt/gnupg-2.0.17/RDEPEND

 !static? ( >=dev-libs/libassuan-2 >=dev-libs/libgcrypt-1.4 >=dev-libs
 >=dev-libs/libksba-1.0.7 >=dev-libs/pth-1.3.7 >=net-misc/curl-7.10 adns? (
 >=net-libs/adns-1.4 ) bzip2?
 ( app-arch/bzip2 ) pcsc-lite? ( >=sys-apps/pcsc-lite-1.3.0 ) openct? (
 >=dev-libs/openct-0.5.0 )
 smartcard? ( =virtual/libusb-0* ) ldap? ( net-nds/openldap ) ) || ( app-
 app-crypt/pinentry-qt ) virtual/mta !app-crypt/gnupg !<=app-
 crypt/gnupg-2.0.1 selinux? (
 sec-policy/selinux-gnupg ) nls? ( virtual/libintl )

 Somehow those self-blocks entered the installed-repository. I could remove
 the blocks manually, but I wanted to report the issue before trying to fix
 my system, so you can ask for more information if you think it is a bug. I
 will provide additional information in attached files:

 * cave show output for gnupg and cryptsetup
 * cave resolve --explain for gnupg and cryptsetup
 * relevant paludis.log excerpt

 The whole problem does not make a lot of sense to me. Why did the world
 update resolve in the first place? If the self-blocks were not in place at
 that time, they had to be added during the world update. But as far as I
 can see from paludis.log cryptsetup and gnupg were not touched during the
 update process. And if the blocks were there, why didn't they matter at

 I might have overlooked or forgotten to mention something. Maybe it is a
 good idea to record the whole "cave resolve [...]" commands in
 /var/log/paludis.log on execution of the resolution in future versions of
 paludis to be able to reconstruct such issues? Just a thought.

 Anyways there is one thing that caught my attention. In both cases the
 self-blocking depend atom in the installed-repository replaced another
 atom which is nowhere to be found:

 '''in sys-fs/cryptsetup-1.1.3-r3:'''

 !sys-fs/cryptsetup-luks (in gentoo-repository's DEPEND list) was replaced
 by !sys-fs/cryptsetup (in installed-repository's DEPEND list)

 '''in app-crypt/gnupg-2.0.17:'''

 !app-crypt/gpg-agent (in gentoo-repository's RDEPEND list) was replaced by
 !app-crypt/gnupg (in installed-repository RDEPEND list)

 PS: Part of my system is now unusable due to the incomplete world update,
 so I will fix the block manually by the end of the weekend.

Ticket URL: <http://trac.pioto.org/paludis/ticket/1161>
Paludis <http://paludis.pioto.org/>
Paludis, the Other Package Mangler

More information about the paludis-dev mailing list