From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from pigeon.gentoo.org ([69.77.167.62] helo=lists.gentoo.org) by finch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1JZsTi-0004AN-86 for garchives@archives.gentoo.org; Thu, 13 Mar 2008 18:48:34 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 03E77E0774; Thu, 13 Mar 2008 18:48:33 +0000 (UTC) Received: from aei-tech.com (static-69-95-200-80.ind.choiceone.net [69.95.200.80]) by pigeon.gentoo.org (Postfix) with ESMTP id CB564E076F for ; Thu, 13 Mar 2008 18:48:32 +0000 (UTC) Received: (qmail 30215 invoked from network); 13 Mar 2008 18:48:30 -0000 Received: from unknown (HELO www.aei-tech.com) (192.168.1.1) by 192.168.1.1 with SMTP; 13 Mar 2008 18:48:30 -0000 Received: from 192.168.2.159 (SquirrelMail authenticated user ctennis) by www.aei-tech.com with HTTP; Thu, 13 Mar 2008 14:48:30 -0400 (EDT) Message-ID: <55402.192.168.2.159.1205434110.squirrel@www.aei-tech.com> In-Reply-To: <1205426349.7261.14.camel@inertia.twi-31o2.org> References: <430880c50803121635g294f505av259707f7e6a746bb@mail.gmail.com> <1205415290.17945.19.camel@nc.nor.wtbts.org> <47D92F32.8070703@gentoo.org> <47D930BC.3050708@gentoo.org> <52737.192.168.2.159.1205417733.squirrel@www.aei-tech.com> <1205426349.7261.14.camel@inertia.twi-31o2.org> Date: Thu, 13 Mar 2008 14:48:30 -0400 (EDT) Subject: Re: [gentoo-dev] Help offered - Portage tree From: "Caleb Tennis" To: gentoo-dev@lists.gentoo.org User-Agent: SquirrelMail/1.4.10a Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 X-Priority: 3 (Normal) Importance: Normal Content-Transfer-Encoding: quoted-printable X-Archives-Salt: 65e7a947-bef3-4add-9c55-24d157bdb780 X-Archives-Hash: 63937aeca086d81fb5fcd9f95cc5a011 >> I use this example because it's actually hit me before, but it extends= to lots of >> other scenarios. The obvious fix is to either use --deep, or just mak= e sure you >> need machine 2 up to date with machine 1, though that's difficult to d= o when >> you're >> talking about machine 301 and machine 559. > > As much as I hate to say it, your example was rather bunk, because > openssl changed SONAME during that time. Keeping the package You're right here. After review, the problem was the difference between = 0.9.8e and 0.9.8g, the latter of which provided some form of newer symbol that wasn'= t in e.=20 But the concept is the same. > information isn't *nearly* as important and doing some checking on the > package. It sounds more like we need to keep some additional > information around, so checks on things like NEEDED can be done. > Perhaps some new "LIBRARIES" file which lists libraries installed by th= e > package. Then, prior to merge, $package_manager could check NEEDED > versus RDEPEND versus LIBRARIES and bail if something's not > right/missing. In this case, even if the RDEPEND was >>=3Ddev-libs/openssl-0.9.7 and you have 0.9.8, it would fail because > NEEDED would list libssl.so.0.9.7, but LIBRARIES would only have > libssl.so.0.9.8 in it. This seems perfectly acceptable to me. > Uhh... >=3D in RDEPEND does that, already... Also, this wouldn't have > resolved your openssl issue, at all. Your machine scenario above would > have still failed, since the minimum version was 0.9.7 on your build > host. I'm not talking about meeting the minimum required by the ebuild, I'm tal= king about the minimum that were installed at the time of the emerge. > Well, I sincerely hope that you do not file such a bug, as it would > royally screw over the one team in Gentoo that *does* consistently use > our binary package support. I don't plan on filing the bug, but if it was an optional emerge option t= o use the actual version deps vs. the DEPEND of the ebuild, it wouldn't affect you = would it? > I would definitely like to see the support improved, but not at the > expense of doing very stupid things like locking to specific > versions/revisions of packages. No offense, but that screams of RPM > hell. I'm not trying to lock to any specific version. I'm trying to reproduce = on machine 2 the same state of packages that package A was compiled against on machi= ne 1. And even make it optional to do so, via an emerge flag. --=20 gentoo-dev@lists.gentoo.org mailing list