Re: [gentoo-dev] Script to clean old files from /usr/portage/distfiles

[Marko Mikulicic]

José Fonseca wrote:
> On Tue, Nov 12, 2002 at 01:29:44AM +0100, Marko Mikulicic wrote: >
>
> ...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 wrong
> 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: 
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 
at any instant.
Obviously it doesnt cache /var/db/pkg because overlay ebuild are listed 
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 
exist

>
> 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 are
> 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 outcome
>    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 
least only '-p')
option.  However, my opinion is that first we should have a working 
script that helps
somebody who knows what he want, and then

>
> 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 
ther (for example
xfree 4.2.1 X_DRIVERS, MS_FONT_URLS, ....). you should evaluate the 
ebuild in order
to resolve local script variables; not a simple sed. And then evaluating 
the script is not so
simple because of "inherits" and other commands not defined there. I had 
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 
all packages which
have passed emerge. Why duplicate the work. Emerge produced the output, 
why don't use it.
I think that the question about portage overlay is not to be solved here 
but with a more general solution.

Marko


--
gentoo-dev@g.o mailing list