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 1JZoQa-0005WW-Pc for garchives@archives.gentoo.org; Thu, 13 Mar 2008 14:29:05 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 712E6E0984; Thu, 13 Mar 2008 14:27:49 +0000 (UTC) Received: from mail.esiee.fr (mail.esiee.fr [147.215.1.3]) by pigeon.gentoo.org (Postfix) with ESMTP id 0E214E0984 for ; Thu, 13 Mar 2008 14:27:49 +0000 (UTC) Received: from mail.esiee.fr (localhost [127.0.0.1]) by VAMS.dummy (Postfix) with SMTP id 44534CAED for ; Thu, 13 Mar 2008 15:27:48 +0100 (CET) Received: from secure.esiee.fr (secure.esiee.fr [147.215.1.19]) by mail.esiee.fr (Postfix) with ESMTP id 36211CAED for ; Thu, 13 Mar 2008 15:27:48 +0100 (CET) Received: from [10.30.0.50] (wiki.comwax.com [88.191.63.61]) (using SSLv3 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: dartigug) by secure.esiee.fr (Postfix) with ESMTP id 94714E7A33 for ; Thu, 13 Mar 2008 15:27:47 +0100 (CET) Subject: Re: [gentoo-dev] Help offered - Portage tree From: Gilles Dartiguelongue 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: text/plain; charset=utf-8 Organization: Gentoo Date: Thu, 13 Mar 2008 15:25:57 +0100 Message-Id: <1205418357.15182.6.camel@woix.comwax.com> 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 Content-Transfer-Encoding: quoted-printable X-Archives-Salt: df92f36b-7b49-4f35-9cd4-a100efef851a X-Archives-Hash: 65f4d4a3d313783ba6874398f0345c11 Le jeudi 13 mars 2008 =C3=A0 10:15 -0400, Caleb Tennis a =C3=A9crit : > > +1 on that and if people who use binary pkgs don't tell us what break= s, > > we won't know. >=20 > I'll kick it off, then. >=20 > The binpkg format needs some way to store the actual versions of the de= pendencies as > they were on the machine the package was compiled on. Then, when emerg= ing the > binpkg, someway to force those dependencies on the new install machine = would be > nice. >=20 > I'll give an example. Package A was built on machine 1, and has a dep = on > >=3Dopenssl-0.9.7. Machine 1 has openssl-0.9.8 already installed. Bin= ary package > built, no problem. >=20 > Now, we attempt to install binary package A on machine 2, which has ope= nssl-0.9.7.=20 > It installs fine, deps met. But, whoops, there's some symbols missing = when we go to > use package A on machine 2. After some time, we finally realize it's b= ecause we > need new openssl. >=20 > 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= sure you > need machine 2 up to date with machine 1, though that's difficult to do= when you're > talking about machine 301 and machine 559. >=20 > If there was a way to tell the bin package installer to make sure you m= et all of the > same minimum verisons of the deps as they were on the original compilin= g machine, > that would be fantastic. >=20 > 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 b= inpkg 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. I think remi was more speaking about incorrect deps (say misplaced in RDEPEND) than problems concerning the package manager. In any case, openssl is the perfect example of what can go wrong because of upstream's behavior. The problem is that program A compiled against version X of openssl won't work with version Y>X. Currently we need to keep X's libs around and run revdep-rebuild to fix this. Most librairies don't cause this problem though so I don't really see this as a bug on the gentoo side even if it's annoying. Anyway, to keep machines using binary in sync without much headache, my current solution is to use a squashfsed portage tree with --deep. It works pretty well. --=20 Gilles Dartiguelongue Gentoo -- gentoo-dev@lists.gentoo.org mailing list