busybox recipe isappearances

busybox recipe isappearances

[Koen Kooi]

Hi,

Why are people removing busybox recipes that angstrom has in 
PREFERRED_VERSIONS? QA gets really hard to do if things in 
PREFERRED_VERSIONS dissappear and unwanted versions get built....

Re: busybox recipe isappearances

[Michael 'Mickey' Lauer]

Am Sunday 19 October 2008 18:11:57 schrieb Koen Kooi:
> Hi,
>
> Why are people removing busybox recipes that angstrom has in
> PREFERRED_VERSIONS? QA gets really hard to do if things in
> PREFERRED_VERSIONS dissappear and unwanted versions get built....

Ack. Been bitten my that more than once. We should either leave the versions 
and just add newer ones or change the preferred-providers to match (if sure 
it's a minor update of a stable version). 

(This time it was an error on my side though.)

-- 
:M:

Re: busybox recipe isappearances

[Phil Blundell]

On Sun, 2008-10-19 at 18:47 +0200, Michael 'Mickey' Lauer wrote:
> Ack. Been bitten my that more than once. We should either leave the versions 
> and just add newer ones or change the preferred-providers to match (if sure 
> it's a minor update of a stable version). 
> 
> (This time it was an error on my side though.)

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. 

Making an explicit distinction between minor and major updates as far as
PREFERRED_VERSION goes is quite an interesting idea though.  I can
certainly imagine that I might, for example, want to pin libglib to
2.14.x but be prepared to accept minor version updates within that
series.  I don't think there's currently any syntax to allow that but it
would be a neat enhancement.

p.

Re: busybox recipe isappearances

[Richard Purdie]

On Sun, 2008-10-19 at 18:46 +0100, Phil Blundell wrote:
> On Sun, 2008-10-19 at 18:47 +0200, Michael 'Mickey' Lauer wrote:
> > Ack. Been bitten my that more than once. We should either leave the versions 
> > and just add newer ones or change the preferred-providers to match (if sure 
> > it's a minor update of a stable version). 
> > 
> > (This time it was an error on my side though.)
> 
> 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. 
> 
> Making an explicit distinction between minor and major updates as far as
> PREFERRED_VERSION goes is quite an interesting idea though.  I can
> certainly imagine that I might, for example, want to pin libglib to
> 2.14.x but be prepared to accept minor version updates within that
> series.  I don't think there's currently any syntax to allow that but it
> would be a neat enhancement.

I've also hit a problem where we want PREFERRED_VERSION = "3.4.5+svnrX"
where X can vary with SRCREV. Allowing a * character in the
PREFERRED_VERSION fields could be useful for both problems?

Cheers,

Richard

Re: busybox recipe isappearances

[Michael 'Mickey' Lauer]

Am Sunday 19 October 2008 19:46:55 schrieb Phil Blundell:
> On Sun, 2008-10-19 at 18:47 +0200, Michael 'Mickey' Lauer wrote:
> > Ack. Been bitten my that more than once. We should either leave the
> > versions and just add newer ones or change the preferred-providers to
> > match (if sure it's a minor update of a stable version).
> >
> > (This time it was an error on my side though.)
>
> 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.

> Making an explicit distinction between minor and major updates as far as
> PREFERRED_VERSION goes is quite an interesting idea though.  I can
> certainly imagine that I might, for example, want to pin libglib to
> 2.14.x but be prepared to accept minor version updates within that
> series.  I don't think there's currently any syntax to allow that but it
> would be a neat enhancement.

Agreed, that would be helpful.

-- 
:M:

Re: busybox recipe isappearances

[Phil Blundell]

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.

p.

Re: busybox recipe isappearances

[Thomas Kunze]

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
>   

Re: busybox recipe isappearances

[Florian Boor]

Hi,

Phil Blundell schrieb:
> 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. 

I share this opinion. Since we do not know what people are doing with OE there
is no way to find out if a recipe is used or not. In fact I can imagine a lot of
situations in which you might want to use an older recipe.

Why do we delete old recipes? We do not do this with old software releases.


Greetings

Florian

-- 
The dream of yesterday                  Florian Boor
is the hope of today                    Tel: +49 271-771091-15
and the reality of tomorrow.            Fax: +49 271-771091-19
[Robert Hutchings Goddard, 1904]        florian.boor@kernelconcepts.de
                                        http://www.kernelconcepts.de/en

Re: busybox recipe isappearances

[Eliyahu Skoczylas]

On Thu, 23 Oct 2008 11:39:22 +0200, "Florian Boor"
<florian.boor@kernelconcepts.de> said:
> Hi,
> 
> Phil Blundell schrieb:
> > 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. 
> 
> I share this opinion. Since we do not know what people are doing with OE
> there
> is no way to find out if a recipe is used or not. In fact I can imagine a
> lot of
> situations in which you might want to use an older recipe.
> 
> Why do we delete old recipes? We do not do this with old software
> releases.

I think that a simple policy of retaining, say, the latest 3 or 4
recipes for the current version of a package, and the last 2 for the 2
earlier software versions, might make people's lives easier and also not
"clutter up" the directories with dozens of out-of-date / non-working
versions.  It shouldn't be hard to automate a policy like that, either.

-    Eliyahu
--
Eliyahu Skoczylas    +972 (54) 214-1505
If <EliSko@Eli-Sko.com> bounces, please use <EliSko@FastMail.fm>, instead.

Re: busybox recipe isappearances

[Michael 'Mickey' Lauer]

Am Thursday 23 October 2008 11:39:22 schrieb Florian Boor:
> Phil Blundell schrieb:
> > 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.
>
> I share this opinion. Since we do not know what people are doing with OE
> there is no way to find out if a recipe is used or not. In fact I can
> imagine a lot of situations in which you might want to use an older recipe.
>
> Why do we delete old recipes? We do not do this with old software releases.

I think it's really messy and confusing to keep all version of recipes we ever 
had. I'd rather keep only major releases. I know, most of that is taste.

-- 
:M: