Bug 646160 – sys-apps/portage-2.3.21 - questionable list of dependency changes without revision bump

• Status: RESOLVED INVALID
• Product: Portage Development

[Description Carlo 2018-01-30 21:02:57 UTC]

Hi there. Tested the new Portage version and got - corresponding to bug 645780  - a ridiculous long list of more than 500 ebuilds to rebuild.

Here's the result checking two random ebuilds:

diff -u virtual/fortran/fortran-0.ebuild /var/db/pkg/virtual/fortran-0/fortran-0.ebuild

No difference at all.

diff -u media-libs/libaacs/libaacs-0.7.1.ebuild /var/db/pkg/media-libs/libaacs-0.7.1/libaacs-0.7.1.ebuild
--- media-libs/libaacs/libaacs-0.7.1.ebuild     2017-12-09 22:08:18.540271453 +0100
+++ /var/db/pkg/media-libs/libaacs-0.7.1/libaacs-0.7.1.ebuild   2017-07-11 01:23:56.210334931 +0200
@@ -6,8 +6,8 @@
 inherit autotools-multilib

 DESCRIPTION="Open implementation of the Advanced Access Content System (AACS) specification"
-HOMEPAGE="https://www.videolan.org/developers/libaacs.html"
-SRC_URI="https://downloads.videolan.org/pub/videolan/libaacs/${PV}/${P}.tar.bz2"
+HOMEPAGE="http://www.videolan.org/developers/libaacs.html"
+SRC_URI="ftp://ftp.videolan.org/pub/videolan/libaacs/${PV}/${P}.tar.bz2"

 LICENSE="LGPL-2.1"
 SLOT="0"

No dependency change.


In its current form, this feature is not helpful.

[Comment 1 Ben Kohler 2018-01-30 21:22:39 UTC]

You'll probably want to compare /var/db/pkg/media-libs/libaacs-0.7.1/RDEPEND to the RDEPEND line in $gentoo/metadata/md5-cache/media-libs/libaacs-0.7.1

[Comment 2 Carlo 2018-01-30 21:31:29 UTC]

RDEPEND=>=dev-libs/libgcrypt-1.5.3:0[abi_x86_32(-)?,abi_x86_64(-)?,abi_x86_x32(-)?,abi_mips_n32(-)?,abi_mips_n64(-)?,abi_mips_o32(-)?,abi_ppc_32(-)?,abi_ppc_64(-)?,abi_s390_32(-)?,abi_s390_64(-)?] >=dev-libs/libgpg-error-1.12[abi_x86_32(-)?,abi_x86_64(-)?,abi_x86_x32(-)?,abi_mips_n32(-)?,abi_mips_n64(-)?,abi_mips_o32(-)?,abi_ppc_32(-)?,abi_ppc_64(-)?,abi_s390_32(-)?,abi_s390_64(-)?]

vs 

>=dev-libs/libgcrypt-1.5.3:0[abi_x86_64(-)] >=dev-libs/libgpg-error-1.12[abi_x86_64(-)]

This doesn't make it better.

[Comment 3 Zac Medico 2018-01-31 03:43:06 UTC]

(In reply to Carlo from comment #2)
> RDEPEND=>=dev-libs/libgcrypt-1.5.3:0[abi_x86_32(-)?,abi_x86_64(-)?,
> abi_x86_x32(-)?,abi_mips_n32(-)?,abi_mips_n64(-)?,abi_mips_o32(-)?,
> abi_ppc_32(-)?,abi_ppc_64(-)?,abi_s390_32(-)?,abi_s390_64(-)?]
> >=dev-libs/libgpg-error-1.12[abi_x86_32(-)?,abi_x86_64(-)?,abi_x86_x32(-)?,
> abi_mips_n32(-)?,abi_mips_n64(-)?,abi_mips_o32(-)?,abi_ppc_32(-)?,
> abi_ppc_64(-)?,abi_s390_32(-)?,abi_s390_64(-)?]
> 
> vs 
> 
> >=dev-libs/libgcrypt-1.5.3:0[abi_x86_64(-)] >=dev-libs/libgpg-error-1.12[abi_x86_64(-)]

It looks like this is due to a difference in the way the atoms were evaluated. I'll look into making it normalize them prior to comparison.

[Comment 4 Zac Medico 2018-01-31 04:53:27 UTC]

(In reply to Zac Medico from comment #3)
> (In reply to Carlo from comment #2)
> > RDEPEND=>=dev-libs/libgcrypt-1.5.3:0[abi_x86_32(-)?,abi_x86_64(-)?,
> > abi_x86_x32(-)?,abi_mips_n32(-)?,abi_mips_n64(-)?,abi_mips_o32(-)?,
> > abi_ppc_32(-)?,abi_ppc_64(-)?,abi_s390_32(-)?,abi_s390_64(-)?]
> > >=dev-libs/libgpg-error-1.12[abi_x86_32(-)?,abi_x86_64(-)?,abi_x86_x32(-)?,
> > abi_mips_n32(-)?,abi_mips_n64(-)?,abi_mips_o32(-)?,abi_ppc_32(-)?,
> > abi_ppc_64(-)?,abi_s390_32(-)?,abi_s390_64(-)?]
> > 
> > vs 
> > 
> > >=dev-libs/libgcrypt-1.5.3:0[abi_x86_64(-)] >=dev-libs/libgpg-error-1.12[abi_x86_64(-)]
> 
> It looks like this is due to a difference in the way the atoms were
> evaluated. I'll look into making it normalize them prior to comparison.

If tested and it looks like portage already normalizes these properly, so the change was probably triggered by a changed eclass dependency in DEPEND such as the app-portage/elt-patches dependency added by libtool.eclass.

[Comment 5 Carlo 2018-01-31 20:54:14 UTC]

Seems you're right, Zac. I'm back to --dynamic-deps=y. Sorry for the noise.