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 1JZqZo-000586-Dv for garchives@archives.gentoo.org; Thu, 13 Mar 2008 16:46:44 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 9D9D0E08AF; Thu, 13 Mar 2008 16:43:48 +0000 (UTC) Received: from inertia.localdomain (dsl211-165-131.sfo1.dsl.speakeasy.net [74.211.165.131]) by pigeon.gentoo.org (Postfix) with ESMTP id 4459BE08AF for ; Thu, 13 Mar 2008 16:43:48 +0000 (UTC) Received: by inertia.localdomain (Postfix, from userid 1000) id 7D871890610; Thu, 13 Mar 2008 09:39:09 -0700 (PDT) Subject: Re: [gentoo-dev] Help offered - Portage tree From: Chris Gianelloni To: gentoo-dev@lists.gentoo.org In-Reply-To: <52737.192.168.2.159.1205417733.squirrel@www.aei-tech.com> 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> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-mNNyko8IV3H7tND4V7sD" Date: Thu, 13 Mar 2008 09:39:09 -0700 Message-Id: <1205426349.7261.14.camel@inertia.twi-31o2.org> 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 X-Mailer: Evolution 2.12.3 X-Archives-Salt: 160b3c92-6472-4d8b-bc18-6ebc4a736324 X-Archives-Hash: 279058125c2d6477e3c756ddde6dfc59 --=-mNNyko8IV3H7tND4V7sD Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Thu, 2008-03-13 at 10:15 -0400, Caleb Tennis wrote: > > +1 on that and if people who use binary pkgs don't tell us what breaks, > > we won't know. >=20 > The binpkg format needs some way to store the actual versions of the depe= ndencies as > they were on the machine the package was compiled on. Then, when emergin= g the > binpkg, someway to force those dependencies on the new install machine wo= uld be > nice. Please... God... no... > 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 make s= ure you > need machine 2 up to date with machine 1, though that's difficult to do w= hen 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 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 the 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. > If there was a way to tell the bin package installer to make sure you met= all of the > same minimum verisons of the deps as they were on the original compiling = machine, > that would be fantastic. 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. > Now, I'm happy to file a bug and assign it (to the portage team?), but I = view this > really as a wishlist item, and since admittedly very few devs use the bin= pkg stuff, > I didn't see it as something that would probably get acted upon anyway. = I'm not > complaining about that either, just merely stating a fact. 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 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. --=20 Chris Gianelloni Release Engineering Strategic Lead Games Developer --=-mNNyko8IV3H7tND4V7sD Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.7 (GNU/Linux) iD8DBQBH2VitkT4lNIS36YERAuaHAJsGLpMVIAPSI0KZNl3u0HMC/qt2CACdE1um KcHUpPbT3n8LK4IkRSix8ZM= =EGUA -----END PGP SIGNATURE----- --=-mNNyko8IV3H7tND4V7sD-- -- gentoo-dev@lists.gentoo.org mailing list