From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6710 invoked from network); 15 Aug 2004 05:59:15 +0000 Received: from smtp.gentoo.org (156.56.111.197) by lists.gentoo.org with AES256-SHA encrypted SMTP; 15 Aug 2004 05:59:15 +0000 Received: from lists.gentoo.org ([156.56.111.196] helo=parrot.gentoo.org) by smtp.gentoo.org with esmtp (Exim 4.34) id 1BwE2z-0001xW-Na for arch-gentoo-portage-dev@lists.gentoo.org; Sun, 15 Aug 2004 05:59:14 +0000 Received: (qmail 11462 invoked by uid 89); 15 Aug 2004 05:59:12 +0000 Mailing-List: contact gentoo-portage-dev-help@gentoo.org; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail Reply-To: gentoo-portage-dev@lists.gentoo.org X-BeenThere: gentoo-portage-dev@gentoo.org Received: (qmail 5602 invoked from network); 15 Aug 2004 05:59:11 +0000 Date: Sun, 15 Aug 2004 07:59:13 +0200 From: Javier Marcet To: gentoo-portage-dev@lists.gentoo.org Message-ID: <20040815055913.GA4107@marcet.info> Reply-To: Javier Marcet Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="tsOsTdHNUZQcU9Ye" Content-Disposition: inline X-Editor: Vim http://www.vim.org/ X-Operating-System: Gentoo GNU/Linux 2004.2 / 2.6.8-rc4-ck2-marcet i686 AMD Athlon(TM) XP 2000+ AuthenticAMD User-Agent: Mutt/1.5.6i Subject: [gentoo-portage-dev] Portage dependencies hell and PATCH to solve it X-Archives-Salt: dceaeea5-4946-4af6-b610-69a9030d65df X-Archives-Hash: ed56de7d9ece750a27bd22f019efd3d0 --tsOsTdHNUZQcU9Ye Content-Type: multipart/mixed; boundary="3MwIy2ne0vdjdPXF" Content-Disposition: inline --3MwIy2ne0vdjdPXF Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi guys, a long long time ago I began having problems with portage which seemingly only affected me. I talked to some guys on #gentoo-dev or #gentoo-portage (I'm not sure what was the channel) who did take part in portage development, but couldn't fix it. In the 2.0.51_pre series the last version I remember not giving me problems was 2.0.51_pre10, with it I can emerge anything, from source or binary and whatever DEPENDS the ebuild has. =46rom pre11 on I often get errors which always look like (this is with the last one released, pre17): # emerge mozilla -p Invalid package name: moznomail These are the packages that I would merge, in order: Calculating dependencies =20 !!! Problem in net-www/mozilla dependencies. !!! 73 This time I decided to chase the problem until I found it. One thing common to all the errors I was getting with pre17 is that it involved negated dependencies, e.g. the above error results from this RDEPEND in mozilla's ebuild: RDEPEND=3D"java? ( virtual/jre ) crypt? ( !moznomail ( >=3Dapp-crypt/gnupg-1.2.1 ) )" As you may see it is the negated moznomail which has, allegedly, an invalid package name. Another source of errors is depending on inexistent packages (this was the good side of the bug, it found errors within gcc ebuilds). The ebuild hardened-gcc does not exist anymore within portage yet gcc's ebuilds include it within their list of DEPENDs. It is included negated, but it is included: DEPEND=3D"virtual/libc !uclibc? ( >=3Dsys-libs/glibc-2.3.3_pre20040420-r1 ) !uclibc? ( hardened? ( >=3Dsys-libs/glibc-2.3.3_pre20040529 ) ) ( !sys-devel/hardened-gcc ) =2E.. The error for the above is: Invalid package name: sys-devel/hardened-gcc These are the packages that I would merge, in order: Calculating dependencies =20 !!! Problem in sys-devel/gcc dependencies. !!! 73 As you can see, it is quite identical to the one with the negated moznomail. Indeed, now that I think of it, the cause seems the same, the !, not that hardened-gcc does not exist anymnore. Anyhow, I think it is something needing a change. I attach two patches. The first one is the hunk of difference between pre10 and pre11 which made the difference between a clean portage which gives no problems, and a hosed one which often complain about invalid package names. The second one is for the current _pre17. Unlike the former one which affected bin/emerge, thus not touching ebuild.sh, pre17's bug is within pym/portage.py, hence it makes `ebuild` also fail in some situations (which as of now I cannot consistently reproduce, I have traced it enough). Hopefully it solves each and every problem. So far I've been able to do and 'emerge -u world --deep --empty-tree -p' without any error, which I couldn't before due to packages like mozilla, mozilla-firefox or gcc, to name a few. Oddly enough, the change I propose for _pre17 has been on purpose judging by the comments the culprit line is surrounded. I read the bug description and that's not the problem I've always had at all. What I don't understand, but puzzles me quite a bit, is how is it possible that this only shows on my systems? This has been present since 2.0.49_something, with a lot of portage released versions making havoc. I tried fresh installs, without moving portage's dir to customs paths or anything like that and even so the bug hit me, on different machines. All of them set up by me, though. It seems it's me rather than the system having the problems. Suggestions, comments, explanations for this behavior will be highly appreciated. Thanks for your help & time. P.S I'm sorry for not narrowing down the first patch a little bit more, but I haven't yet learned Python, maybe I do in the coming months, but ATM I'm happy enough hacking with C, C++ & Perl all day long :) --=20 Captain's Log, star date 21:34.5... =D6=01 Javier Marcet --3MwIy2ne0vdjdPXF Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="portage-2.0.51_pre11-dependencies_hell.fix" Content-Transfer-Encoding: quoted-printable --- bin/emerge 2004-08-15 03:19:17.000000000 +0200 +++ bin.orig/emerge 2004-08-15 03:19:08.000000000 +0200 @@ -829,18 +823,9 @@ merging=3D2 if merging=3D=3D1: mybigkey.append("merge") - self.mydbapi[myroot].cpv_inject(mykey) else: mybigkey.append("nomerge") =09 - virts =3D portage.db[myroot]["porttree"].dbapi.aux_get(mykey, ["PROVIDE"= ])[0].split() - cp =3D portage.dep_getkey(mykey) - for virt in virts: - virt =3D portage.dep_getkey(virt) - while cp in portage.virts[virt]: - portage.virts[virt].remove(cp) - portage.virts[virt].insert(0, cp) - =09 # whatever the case, we need to add the node to our digraph so # that children can depend upon it. self.digraph.addnode(string.join(mybigkey),myparent) --3MwIy2ne0vdjdPXF Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="portage-2.0.51_pre17-dependencies_hell.fix" --- pym/portage.py.orig 2004-08-05 13:24:41.000000000 +0200 +++ pym/portage.py 2004-08-15 07:04:55.954353680 +0200 @@ -3932,7 +3932,7 @@ if mydep!=None: tmp=(len(mydep)>=1) if deplist[mypos][0]=="!": - #tmp=not tmp + tmp=not tmp # This is ad-hoc code. We should rewrite this later.. (See #52377) # The reason is that portage uses fakedb when --update option now. # So portage considers that a block package doesn't exist even if it exists. @@ -3940,7 +3940,7 @@ # ==== start # emerge checks if it's block or not, so we can always set tmp=False. # but it's not clean.. - tmp=False + #tmp=False # ==== end deplist[mypos]=tmp else: --3MwIy2ne0vdjdPXF-- --tsOsTdHNUZQcU9Ye Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.9.10 (GNU/Linux) iEYEARECAAYFAkEe+7EACgkQx/ptJkB7fryh8QCfZcYRAh27j4734sqAKrFT4VhN 2aIAmgIGGUEMLFZYgRit5U76eTunybTL =Riaq -----END PGP SIGNATURE----- --tsOsTdHNUZQcU9Ye--