Ticket #1161 (closed ebuild-defect: upstream)

Opened 9 years ago

Last modified 9 years ago

inexplicable self-blocking depend atoms in installed-repository

Reported by: christian. Owned by:
Priority: Sometime Milestone:
Component: clients/cave Version: 0.60.4
Keywords: Cc:
Blocked By: Blocking:
Distribution: Gentoo

Description

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-base/kdelibs
    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

DEPEND="${RDEPEND}
        !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 )
                dev-libs/libgcrypt[static-libs]
        )"

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 popt.cave

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/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 ) 
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/libgpg-error-1.7 
>=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-crypt/pinentry 
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 first?

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.

Attachments

cave_resolve_lafilefixer_with_explain.text Download (8.8 KB) - added by christian. 9 years ago.
cave_show_gnupg_cryptsetup.text Download (5.9 KB) - added by christian. 9 years ago.
excerpt_of_paludis.log.lzma Download (5.8 KB) - added by christian. 9 years ago.
paludis log excerpt -- had to compress because of spam filter and not working captcha

Change History

Changed 9 years ago by christian.

Changed 9 years ago by christian.

Changed 9 years ago by christian.

paludis log excerpt -- had to compress because of spam filter and not working captcha

comment:1 Changed 9 years ago by ciaranm

  • Status changed from new to closed
  • Type changed from defect to ebuild-defect
  • Resolution set to upstream

The cause is package moves. Some moved ebuilds incorrectly block their own old name. Thus, when a package move occurs, that block is rewritten on the installed package to block the new name instead.

The correct fix is to file a bug for any package that does this, pointing out  http://www.mail-archive.com/gentoo-dev@lists.gentoo.org/msg42102.html .

comment:2 Changed 9 years ago by christian.

I see now. I probably did a "cave sync" in between the USE flag change and world update. Will report it upstream. Thx a lot.

comment:3 Changed 9 years ago by christian.

Reported app-crypt/gnupg upstream to Gentoo -- a bug for sys-fs/cryptsetup will follow if a solution is found:

 http://bugs.gentoo.org/show_bug.cgi?id=367215

Note: See TracTickets for help on using tickets.