Re: RFD: Recipe variants, multilib and package handling

[Tom Rini <tom_rini@mentor.com>]

On 06/13/2011 04:52 AM, Richard Purdie wrote:

[snip]
> Discussion
> ==========
> 
> I don't think option a) above is viable and the current plan implies
> we'd do b) but its extremely ugly. I'm therefore tempted to look more
> seriously at c). The bigger issues would appear to be:
> 
> * It breaks with convention/tradition for OE (xxx-native vs native:xxx)

True, but how long do we stick with things that are limiting us when we
need a change to fix a real problem?  And this is a little easier to
deal with, now that we do really have a notion of doing releases so we
can more easily explain to folks when the change is.

> * It would add the constraint of packaging starting with ${PN}

I know we have some, but do they also really have a good reason for not
being ${PN}-foo now, possibly other than we borrowed the notion there
from someone else?  For example, I know Ubuntu is still 'ssh' for
'openssh', but we don't do that one.

> * It would require changes to the likes of debian.bbclass to account 
>   for package prefixes when performing auto renaming

Maybe we need to rename debian.bbclass while we're at it and yes, taking
into account multilib is, to me, just a 'yeah, gonna have to' as part of
the problem.

> * It would break a small set of the metadata where packages don't start 
>   with ${PN} (although the class could simply refuse to extend these 
>   automatically).

I think refusing is a good starting point to encourage someone that
needs it to update the recipe, or it can be a janitor project in the end
if the set is small enough...

> Things to consider:
> 
> * Would we just do this for multilibs or would we transition native 
>   recipes to the new style of naming? We don't have PACKAGES problems 
>   for native recipes.

I see a positive here being one less thing to change, but the downside
being one more set of logic sitting around.  Perhaps as a second pass
migrating native over...

> * Likewise, would nativesdk transition? Is has more PACKAGES problems 
>   so likely yes, it would make sense to transition.

I think it'll have to, at least before it's all said and done, otherwise
you will run into someone extending for both and puzzling over the
different names they get.

> * Would we stick with "-" as a delimiter or switch to something like 
>   ":"?

Internally, that might make things easier but in terms of writing out
the packages, that could be a problem...

> Thoughts/suggestions/better ideas welcome...

I wish it was easier to abstract things away so we could get namespace B
and keep that information around to solve problem 'i'.  Then problem
'ii' would just be about changing how we define PN.

-- 
Tom Rini
Mentor Graphics Corporation