All of lore.kernel.org
 help / color / mirror / Atom feed
From: Thomas Kunze <thommycheck@gmx.de>
To: openembedded-devel@lists.openembedded.org
Subject: Re: busybox recipe isappearances
Date: Mon, 20 Oct 2008 13:22:38 +0200	[thread overview]
Message-ID: <48FC69FE.2020300@gmx.de> (raw)
In-Reply-To: <1224488828.4235.278.camel@lenovo.internal.reciva.com>

Phil Blundell wrote:
> On Mon, 2008-10-20 at 00:02 +0200, Michael 'Mickey' Lauer wrote:
>   
>> Am Sunday 19 October 2008 19:46:55 schrieb Phil Blundell:
>>     
>>> It's long been my view that we should just add newer ones and leave the
>>> old ones alone.  There's really no reason to delete old recipes and,
>>> even if you check for PREFERRED_VERSIONs in the git tree, there is no
>>> real way to know who else might be relying on the version you are about
>>> to delete.
>>>       
>> That's true, however I always feel the urge of cleaning up when I see dozens 
>> or recipes for the same software [besides the amount of increased parsing 
>> efforts if we really were to keep everything). I'd rather have the rough 
>> guideline of keeping major (trusted) releases. At the end of the day, 
>> everything is in the archives.
>>     
>
> If parsing time were to become a big issue then one could imagine ways
> to solve that in bitbake.  For example, one could arrange for a command
> like "bitbake --disregard-old-versions" to parse all the files once,
> identify those versions which are older than the PREFERRED ones (whether
> set explicitly or automatically), and blacklist these old versions so
> that they are never parsed again.  The effect would be a bit like having
> an automatically-maintained BBMASK though of course the implementation
> would probably be slightly different.
>
> As for old versions being in the archives, that's true, but it seems
> like one could easily get into a kind of ping-pong thing where you
> delete an old version, I pull it out of the archives again, someone else
> now notices this "old cruft" and deletes it again, and so on.  I can
> imagine that being frustrating for all parties.
>   
This could be avoided if both parties would read the commit messages ;)
> p.
>
>
>
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>   




  reply	other threads:[~2008-10-20 11:22 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-10-19 16:11 busybox recipe isappearances Koen Kooi
2008-10-19 16:47 ` Michael 'Mickey' Lauer
2008-10-19 17:46   ` Phil Blundell
2008-10-19 18:08     ` Richard Purdie
2008-10-19 22:02     ` Michael 'Mickey' Lauer
2008-10-20  7:47       ` Phil Blundell
2008-10-20 11:22         ` Thomas Kunze [this message]
2008-10-23  9:39     ` Florian Boor
2008-10-23 10:12       ` Eliyahu Skoczylas
2008-10-27 13:26       ` Michael 'Mickey' Lauer

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=48FC69FE.2020300@gmx.de \
    --to=thommycheck@gmx.de \
    --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.