On 03/15/2011 06:14 AM, Philip Balister wrote:
On 03/14/2011 07:13 PM, Tom Rini wrote:
On 03/14/2011 03:22 PM, Philip Balister wrote:
On 03/14/2011 11:58 AM, Tom Rini wrote:
Hi all,
The TSC has discussed this item at the request of the community and has
come up with the following recommendation which we are looking for
feedback (positive/negative/neutral) before putting this up on the
wiki.
Looks reasonable. One thing I did not see is asking people not to add a
new recipe and delete the old one in separate commits. This makes it
easier to figure out problems when they arise.
So, part of what is envisioned here is that for, grabbing a recent
example, nodejs 0.4.0 to 0.4.2 we just see a git mv, and that's the
normal case for that level of things. But for say 0.4.9 to 0.5.0 (or
would it be 0.6.0? I don't track the project, but next stable release
that's not in 0.4.x) it would be add 0.5.0 one commit, drop 0.4.9 the
next, Does this still fit, given your comment?
The immediate case I am thinking off is the policykit-gnome update.
(Which I think did the add/delete in the same commit). One of the
changes was a configure option change that led to build failures on my
F14 box. I'm not sure how this fits in the scheme you describe since the
versioning seems to lack a major/minor concept. (Well the minor number
is large)
So, policykit-gnome was just adding a new stable version (as default).
The previous one is still there (in part because of pinning of
dependencies to older versions).
Plugging this example into the workflow:
- policykit/policykit-gnome have newer stable versions released.
- Add new version as default, test[1]
- Keep old versions for now due to some distributions pinning glib-2.0
to an older version that policykit > 0.98 (or so) need.
And, that brings us to [1]. FC14 seems to show off a class of bugs that
need squashing. I'd love it if someone can point me at a VMware
compatible image (with functional tools) already installed. That said,
I think I meant to post to the ML and forgot, or no one saw the
EXTRA_OECONF bug in the recipe that Koen fixed which I think fixes your
problem.
In a perfect world, what you are describing is great, however I'm
concerned the "special cases" may be an issue.
The special cases being the critical infrastructure? Or the unclear
version policy?
--
Tom Rini
Mentor Graphics Corporation
_______________________________________________
Openembedded-devel mailing list
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
