[OE-core] RFD: Recipe variants, multilib and package handling
Tom Rini
tom_rini at mentor.com
Mon Jun 20 22:40:23 UTC 2011
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
More information about the Openembedded-core
mailing list