From mboxrd@z Thu Jan 1 00:00:00 1970
Return-Path: <gentoo-dev-return-107-arch-gentoo-dev=gentoo.org@gentoo.org>
Received: (qmail 21093 invoked by uid 1002); 12 Nov 2002 01:51:28 -0000
Mailing-List: contact gentoo-dev-help@gentoo.org; run by ezmlm
Precedence: bulk
List-Post: <mailto:gentoo-dev@gentoo.org>
List-Help: <mailto:gentoo-dev-help@gentoo.org>
List-Unsubscribe: <mailto:gentoo-dev-unsubscribe@gentoo.org>
List-Subscribe: <mailto:gentoo-dev-subscribe@gentoo.org>
List-Id: Gentoo Linux mail <gentoo-dev.gentoo.org>
X-BeenThere: gentoo-dev@gentoo.org
Received: (qmail 21084 invoked from network); 12 Nov 2002 01:51:27 -0000
Message-ID: <3DD05E70.302@seul.org>
Date: Tue, 12 Nov 2002 02:50:40 +0100
From: Marko Mikulicic <marko@seul.org>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.1) Gecko/20021109
X-Accept-Language: hr, en-us, en
MIME-Version: 1.0
To: =?ISO-8859-15?Q?Jos=E9_Fonseca?= <j_r_fonseca@yahoo.co.uk>
Cc: gentoo-dev@gentoo.org
References: <20021111203828.GA10784@localhost.localdomain> <3DD04B78.9010806@seul.org> <20021112005419.GA27162@localhost.localdomain>
X-Enigmail-Version: 0.65.2.0
X-Enigmail-Supports: pgp-inline, pgp-mime
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: quoted-printable
X-MIME-Autoconverted: from 8bit to quoted-printable by ls405.hinet.hr id gAC1of210918
Subject: Re: [gentoo-dev] Script to clean old files from /usr/portage/distfiles
X-Archives-Salt: 0e494f58-498b-4bd8-aaf7-f72729db59c4
X-Archives-Hash: 25b3d63c4bcf6452d403c0001f241f4a
Jos=E9 Fonseca wrote:
> On Tue, Nov 12, 2002 at 01:29:44AM +0100, Marko Mikulicic wrote: >
>=20
> ...but becare full with these - you should keep them because they're
> really not defined on the above files and the getting the last one wron=
g
> will lead to the deletion of all files in distfiles...!
oh. I didn't checked. I just thought it was from there.
Now that I'm looking better I've seen:=20
portage.settings["PORTAGE_CACHEDIR"] in /usr/bin/emerge
rsync (or sync). From what is the portage cache built ?
Since it is a cache it should mean that i caches some other
information wich remains present on disk, and the cache could be rebuilt=20
at any instant.
Obviously it doesnt cache /var/db/pkg because overlay ebuild are listed=20
there. Where
is the base data (meta-) which /usr/portage/metadata/cache caches ?
This also should solve the errors Johannes and me are getting.
for example:
$ qpkg linux-headers -I -v
sys-kernel/linux-headers-2.4.19
but /usr/portage/metadata/cache/sys-kernel/linux-headers-2.4.19 doesn't=20
exist
>=20
> The way the script work is first get the list of all sources related
> with the installed files from portache cache, merge it with the list of
> sources in distfiles, and delete those which are unique - i.e., only ar=
e
> in distfiles.
> There are two caveats with this procedure:
> - it will delete sources of packages in PORTAGE_OVERLAY, if you have
I don't understand why packages in PORTAGE_OVERLAY are not put in the
/usr/portage/metadata/cache.
They are in /var/db/pkg/ and should be treaten like any other ebuild.
> - if the cache is busted (or can't be found), the most probable outcom=
e
> is that all files in distfiles get deleted... so a good idea is to
> replace 'rm' by 'echo' to get an idea of what is gonna be deleted.
I guess that simplicity or elegance would be completely destroyed
when introducing commandline parsing for the gentooish --pretend (or at=20
least only '-p')
option. However, my opinion is that first we should have a working=20
script that helps
somebody who knows what he want, and then
>=20
> These two caveats could be overcomed by getting the sources directly
> from the installed ebuilds, but that would be terribly slow compared
> with this, due to the parsing of all ebuilds.
yes, because of the ${P} or ${PN} or who knows what other triks are in=20
ther (for example
xfree 4.2.1 X_DRIVERS, MS_FONT_URLS, ....). you should evaluate the=20
ebuild in order
to resolve local script variables; not a simple sed. And then evaluating=20
the script is not so
simple because of "inherits" and other commands not defined there. I had=20
some problems
while writting emerge-rsync (it will be there in the next gentoolkit).
I think your choice is not only the faster but also it will work with=20
all packages which
have passed emerge. Why duplicate the work. Emerge produced the output,=20
why don't use it.
I think that the question about portage overlay is not to be solved here=20
but with a more general solution.
Marko
--
gentoo-dev@gentoo.org mailing list