Franklin, I put this discussion on back-burner for a bit, to let the dust settle and to gather some thoughts...
On Tue, Mar 19, 2013 at 01:50:22PM +0000, Cooper Jr., Franklin wrote: > I am not in favor for some of these new namespace changes for legacy > recipes. There are a lot of history behind those recipes names > (arago-classic) including the PSP version. Old documentation also refer to > that PSP release > http://processors.wiki.ti.com/index.php/DaVinci_PSP_03.21.00.04_Release_Notes > > Ex > u-boot-am180x: modify am180x specific version to use new namespace feature > > --- a/recipes-bsp/u-boot/u-boot_2010.12-psp03.21.00.04.sdk.bb > > +++ b/recipes-bsp/u-boot/u-boot-am180x_2010.12.bb > > > I don't have a problem with adding the machine name to the recipe especially > if COMPATIBLE_MACHINE is set for only one machine. I understand your position here. I happened to have originally introduced those -psp version suffixes to the recipes several years ago. These days this concept is no longer relevant... Let me list few reasons: 1. The internal org has changed, hence the naming - new recipes don't have this same suffix. 2. Other recipes also come from different sources and don't have -psp suffix. 3. The recipe you mentioned above for am180x happens to be the only one left with this suffix - time to unify versioning schema. 4. Yocto principles and the concept of "rolling" releases - meaning not having multiple versions of the same recipe around and using SCM for historic purposes, not the metadata. In other words - there are git tags, branches and even linear history for past versions, so no need to cling to them in the recipes. That means if we have a newer u-boot available for am180x that works, we would remove the 2010.12 as being very old one, PSP or not. 5. With the SoC/machine in the recipe name, there's no worry to have the name collision between u-boot_2010.12 for am180x and the same u-boot version for another machine, so no need to keep the -psp versioning suffix for the purpose of unique version. 6. The PSP version corresponding to that release is still recorded inside the recipe, as a tag/SRCREV. 7. I know you need to set PSPREL variable for the SDK - we can still do that in meta-arago as a bbappend. > Also changing the ti33x PREFERRED_PROVIDER to a kernel that is still being > developed (not released) is another problem. > > Ex: > > ti33x: switch default preference to ti-staging tree > > PREFERRED_PROVIDER_virtual/kernel = "linux-ti-staging" As Chase mentioned, this is gearing up for the release next month and we need as many people to start using and testing it, as possible, at least within meta-ti. Again, for SDK stable releases, it can be set to an older 3.2 version - it's just a matter of setting PREFERRED_PROVIDER and PREFERRED_VERSION accordingly. -- Denys _______________________________________________ meta-ti mailing list meta-ti@yoctoproject.org https://lists.yoctoproject.org/listinfo/meta-ti
