All of lore.kernel.org
 help / color / mirror / Atom feed
From: "John Willis" <John.Willis@Distant-earth.com>
To: <openembedded-devel@lists.openembedded.org>
Subject: Re: checksums situation
Date: Fri, 13 Feb 2009 19:41:59 -0000	[thread overview]
Message-ID: <029801c98e13$26b15b10$74141130$@Willis@Distant-earth.com> (raw)
In-Reply-To: <871vu2chee.fsf@neumann.lab.ossystems.com.br>

> >> <...>
> >>> This solution also has one nasty part - now we can keep SRC_URI for
> >>> multiple versions in common file, but if we switch to storing it in
> >>> SRC_URI we will have to change that.
> >>>
> >>> Other solution proposed on IRC was to keep checksums in extra file
> in
> >>> each directory of packages/ subdirectory. I think that it is not
> best
> >>> but sounds better then one file.
> >>>
> >>> What do you think? Which way we should go? Do you have other ideas?
> >> <...>
> >>
> >> What about having a checksums for _each_ recipe?
> >>
> >> foo_1.0.bb
> >> foo_1.0.md5sum
> >
> > This will waste directories and will make tree navigation harder.
> 
> Well; so let's just create a md5sums directory at OE topdir and add the
> dirs and files there.

Why not take that a little further and just have a checksums dir at the root
with a 'downloadname'.manifest with MD5 and SHA256 hashes? Take the
formatting from Gentoo if people want to. Plenty of scope to be flexible in
the future then without committing to some name stamped method ;-).

I think the URL pre filename is a bit of a non issue as it stands mind you
and I am not sure that the current checksums.ini approach is as bad as all
that if it dropped dupes and URLs. Maybe a little refinement is needed but a
wholesale change seems a little extreme (but I can see pros and cons for
both). As long as it is kept clean and contained and does not break overlays
to much I guess I am happy.

Regards,

John





  parent reply	other threads:[~2009-02-13 19:43 UTC|newest]

Thread overview: 51+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-02-13 16:28 checksums situation Marcin Juszkiewicz
2009-02-13 17:08 ` Otavio Salvador
2009-02-13 17:39   ` Ihar Hrachyshka
2009-02-13 18:37     ` Otavio Salvador
2009-02-13 19:35       ` Leon Woestenberg
2010-02-12 18:45         ` mike
2009-02-13 19:41       ` John Willis [this message]
2009-02-15 10:04       ` Phil Blundell
2009-02-15 18:32         ` Otavio Salvador
2009-02-13 17:09 ` Tom Rini
2009-02-13 17:28 ` Andrea Adami
2009-02-13 17:34   ` Andrea Adami
2009-02-13 18:02 ` Koen Kooi
2009-02-14 14:51 ` Yuri Bushmelev
2009-02-24  6:46 ` Tom Rini
2009-02-24  6:51   ` Tom Rini
2009-02-24  8:49   ` Marcin Juszkiewicz
2009-02-24 15:02     ` Tom Rini
2009-02-24 16:13   ` Michael 'Mickey' Lauer
2009-02-24 16:25     ` Angus Ainslie
2009-02-24 16:37       ` Tom Rini
2009-02-24 16:28     ` Philip Balister
2009-02-24 16:36       ` Tom Rini
2009-02-24 22:10       ` GNUtoo
2009-02-24 22:17         ` Tom Rini
2009-02-24 22:29         ` Phil Blundell
2009-02-24 22:42           ` GNUtoo
2009-02-25  9:09           ` Richard Purdie
2009-02-25 23:04             ` Denys Dmytriyenko
2009-02-26 13:28               ` Richard Purdie
2009-02-27  0:20                 ` Otavio Salvador
2009-02-24 18:01     ` Otavio Salvador
2009-02-24 18:36       ` Ihar Hrachyshka
2009-02-24 18:50         ` Tom Rini
2009-02-24 22:20           ` GNUtoo
2009-02-25  2:01           ` Otavio Salvador
2009-02-25  2:25             ` Tom Rini
2009-02-25  9:01               ` Richard Purdie
2009-02-25 21:27               ` Vitus Jensen
2009-02-25 21:35                 ` Tom Rini
2009-02-25 22:04                   ` Vitus Jensen
2009-02-26  8:10                     ` Koen Kooi
2009-02-26 12:50                   ` Bernhard Guillon
2009-02-28  9:57                     ` Alessandro GARDICH
2009-02-28 10:45                       ` Koen Kooi
2009-02-28 10:51                         ` Alessandro GARDICH
2009-02-28 13:12                           ` Philip Balister
2009-02-24 20:29 ` Bernhard Guillon
2009-02-24 22:45   ` GNUtoo
2009-02-25  9:16 ` Koen Kooi
  -- strict thread matches above, loose matches on Subject: below --
2009-02-24 20:00 Frans Meulenbroeks

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='029801c98e13$26b15b10$74141130$@Willis@Distant-earth.com' \
    --to=john.willis@distant-earth.com \
    --cc=openembedded-devel@lists.openembedded.org \
    /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.