Openembedded Core Discussions
 help / color / mirror / Atom feed
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 --]

  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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox