From: Ulf Samuelsson <openembedded-core@emagii.com>
To: Patches and discussions about the oe-core layer
<openembedded-core@lists.openembedded.org>
Subject: Re: Possible stale tags in the download directory
Date: Wed, 07 Dec 2011 12:27:20 +0100 [thread overview]
Message-ID: <4EDF4D98.7060803@emagii.com> (raw)
In-Reply-To: <1323249403.19363.66.camel@ted>
On 2011-12-07 10:16, Richard Purdie wrote:
> On Wed, 2011-12-07 at 09:27 +0100, Ulf Samuelsson wrote:
>> When I look at the "downloads" location I find a lot of files called.
>>
>> "11_usagi_fix.patch.done"
>>
>> but no "11_usagi_fix.patch" file in the directory.
>>
>> If this is a indication of that a patch has been downloaded,
>> what happens if you for some reason or other delete your
>> OE-core directory and keep the downloads directory.
>>
>> When you start from fresh, all the tags are then stale.
>>
>> (Deleting the "downloads" directory seems a bad idea)
>>
>> I think that if there should be tags in the "downloads" directory,
>> they should only reflect things which are downloaded to the
>> "downloads" directory, and nothing else.
>>
>> As for the tags in the directory, I think a better approach
>> is to download a file "tarball.tar.bz2" to a different filename first
>> I.E: "tarball.tar.bz2.in-progress" and if the download completes
>> then move the file to "tarball.tar.bz2".
>> Should remove a lot of clutter from the "downloads" directory.
> What we've tried to do is simplify the fetcher code paths in fetch2.
> There were some many corner/special cases and different code paths it
> was near impossible to tell what was going on. One of the side effects
> is that local file:// urls do touch the done stamp in the same way as
> other downloads. The main reason for those files is now checksum
> tracking. If the done stamps were part of tmpdir, we'd keep checksumming
> the contents of the downloads at each build rather than once after the
> download. The way the implementation works, there is very little risk
> from stale stamps, it would just mean the checksum code wouldn't get
> triggered and that is likely unneeded for a local file:// url anyway.
>
> So yes, its not ideal but looking at the code I'd be surprised if a
> build ever broke due to it.
>
Maybe I am paranoid, but I think I remember seeing tarballs developing
bit rot when moved between different machines.
Could of course clean out the downloads directory, but it would be
nice if the stamps would be in a different directory.
Then I just delete the directory when I move the tarballs.
I tend to use the "downloads" directory for other build systems as well,
to avoid duplication, and having stamps in the directory could have
real bad effects.
I agree that recomputing checksums for each build is not so good,
but doing it once after moving to a new machine, or for each new user
is acceptable (at least to me).
The stamps could be stored in a central location.
"~/.oe/downloads" ?
Con: If you have several repositories, maybe because you
forgot to configure for your central repository,
you may be in trouble.
> Cheers,
>
> Richard
>
>
>
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
--
Best Regards
Ulf Samuelsson
eMagii
next prev parent reply other threads:[~2011-12-07 12:00 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-12-07 8:27 Possible stale tags in the download directory Ulf Samuelsson
2011-12-07 9:16 ` Richard Purdie
2011-12-07 11:27 ` Ulf Samuelsson [this message]
2011-12-07 12:00 ` Koen Kooi
2011-12-07 14:30 ` Ulf Samuelsson
2011-12-07 14:37 ` Paul Eggleton
2011-12-07 15:00 ` Richard Purdie
2011-12-07 21:43 ` Khem Raj
2011-12-07 23:46 ` Ulf Samuelsson
2011-12-07 15:04 ` Richard Purdie
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4EDF4D98.7060803@emagii.com \
--to=openembedded-core@emagii.com \
--cc=openembedded-core@lists.openembedded.org \
--cc=ulf@emagii.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox