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 15:30:38 +0100 [thread overview]
Message-ID: <4EDF788E.60804@emagii.com> (raw)
In-Reply-To: <E5CF0974-DCA6-4DAA-859C-ED40990CC11E@dominion.thruhere.net>
[-- Attachment #1: Type: text/plain, Size: 2752 bytes --]
On 2011-12-07 13:00, Koen Kooi wrote:
> Op 7 dec. 2011, om 12:27 heeft Ulf Samuelsson het volgende geschreven:
>
>> 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.
> And that's why checksums are checked before do_unpack.
Richard says that if the *.done file is there, then the checksum is not
calculated.
Or that is at least how I interpret his comment.
If the check is always there, why the tag?
>
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
--
Best Regards
Ulf Samuelsson
eMagii
[-- Attachment #2: Type: text/html, Size: 4027 bytes --]
next prev parent reply other threads:[~2011-12-07 14:38 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
2011-12-07 12:00 ` Koen Kooi
2011-12-07 14:30 ` Ulf Samuelsson [this message]
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=4EDF788E.60804@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.