From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from pigeon.gentoo.org ([208.92.234.80] helo=lists.gentoo.org) by finch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1OZOw6-0001FG-HY for garchives@archives.gentoo.org; Thu, 15 Jul 2010 13:57:14 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 74B10E091B; Thu, 15 Jul 2010 13:57:11 +0000 (UTC) Received: from mail-bw0-f53.google.com (mail-bw0-f53.google.com [209.85.214.53]) by pigeon.gentoo.org (Postfix) with ESMTP id 19B77E08AE for ; Thu, 15 Jul 2010 13:57:05 +0000 (UTC) Received: by bwz6 with SMTP id 6so959766bwz.40 for ; Thu, 15 Jul 2010 06:57:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:subject:date :user-agent:references:in-reply-to:disposition-notification-to :mime-version:content-type:content-transfer-encoding:message-id; bh=VmkUQRK8p/fgUE8o9Lo4pMYZkbwCkIryp5ZbXcKkzaA=; b=CSdqv2GaGBOizyer2IOSmgo+OK9yH7jrMI740iSogTLkxQ2bb+Cud5ihHalJUNwISd AkJY/k95xaV0k+VS9re0zmFrNLmR6fc7EkYZmkvjFzBuFD0cLGFeSR81Vkw2TS2JNqZf +k1WwDShzh6LevPzBrJ1NMK7xPH1v4rBbwohs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:subject:date:user-agent:references:in-reply-to :disposition-notification-to:mime-version:content-type :content-transfer-encoding:message-id; b=Ry8cXKx1idyRtLBpV6FA/Wj41DU8IZGf+mmORxq/hON/68OCxyB4ySxDO51jfDzuaI /5P+P25J+AE8z0QPLyyQkC5ysrzPbqDvZ7xIrG28HXFx75pQFC8kWw00ZzcOW4hQJaYI l/jl8JlQNW/HTd233I6NX2LT4jqbyCbXe8y3w= Received: by 10.204.47.193 with SMTP id o1mr14761333bkf.134.1279202225335; Thu, 15 Jul 2010 06:57:05 -0700 (PDT) Received: from lebrodyl.localnet (aecb111.neoplus.adsl.tpnet.pl [79.186.53.111]) by mx.google.com with ESMTPS id 24sm6055402bkr.19.2010.07.15.06.57.04 (version=SSLv3 cipher=RC4-MD5); Thu, 15 Jul 2010 06:57:04 -0700 (PDT) From: Maciej Mrozowski To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] Re: Over using preserve_old_lib, don't do that Date: Thu, 15 Jul 2010 15:57:01 +0200 User-Agent: KMail/1.13.5 (Linux/2.6.34-gentoo-r1; KDE/4.4.92; x86_64; ; ) References: <4C2D7E5D.2050008@gentoo.org> <1279184979.22198.1.camel@gdartigu.lan.rep.sj> In-Reply-To: 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="utf-8" Message-Id: <201007151557.02149.reavertm@gmail.com> Content-Transfer-Encoding: quoted-printable X-Archives-Salt: 10be2836-e994-4b1d-a8a9-7a5b6ea735d4 X-Archives-Hash: 91ee5425bbd51c28b1d3ba13392a0279 On Thursday 15 of July 2010 12:14:29 Duncan wrote: > Gilles Dartiguelongue posted on Thu, 15 Jul 2010 11:09:39 +0200 as >=20 > excerpted: > > Le jeudi 15 juillet 2010 =C3=A0 09:49 +0100, Mike Auty a =C3=A9crit := [...] > >=20 > >> I can live with this for in places where it causes massive breakage > >> (openssl/libpng/libjpg), because it's genuinely useful, but I think = it > >> should be restricted to such important packages, or at least disable= d > >> by FEATURES=3D"-preserve-libs". > >>=20 > >> Ideally, these calls should either adhere to FEATURES=3D"-preserve-l= ibs", > >> or there should be a tool that can identify which files portage has > >> preserved, and allow easy rebuilding of dependent packages, and > >> removal. > >>=20 > >> At the moment, I'm having to manually grep ebuilds, ls the librarie= s > >>=20 > >> and run revdep-rebuild over them one at a time... > >=20 > > These sound like very good ideas to me. >=20 > ++ >=20 > If I have FEATURE=3D-preserve-libs, that's what I want. Exceptions sho= uld > be limited to what will break the toolchain (including revdep-rebuild > here, since that's what's normally used to get out of the situation) > itself. >=20 > If there was a way to handle it so a general revdep-rebuild run would > still detect the preserved library as missing and do the necessary > rebuilds, it'd be one thing, but if the libraries are there, it figures > things are OK unless you've fed it that specific library, thereby makin= g a > general revdep-rebuld run useless at the very task it was designed to f= ix. >=20 > Talking about which... What about creating an eutils (or whatever) > function to handle the critical preservations, having it build a > centralized list of them somewhere, and having a revdep-rebuild mode th= at > will treat that list as if it had been fed in with --library on the > command line? Make revdep-rebuild able to run this mode either on its > own, or as part of an otherwise general run, and then you can have > packages (or the package-manager itself, if it uses the list as well) > preserve libs as they wish, without interfering with the ability of rev= dep- > rebuild to detect and resolve the issues in a normal run. And what about using portage 2.2 and be done with it. I don't see the poi= nt in=20 reinventing the wheel yet again. Imho, revdep-rebuild and all 'misc' tools requiring users' good will like= =20 python-updater should be obsolete and phased out in favour of package man= ager=20 controlled mechanisms. --=20 regards MM