On 03/15/2011 02:38 AM, Frans Meulenbroeks wrote:
Tom, thanks for the reply.
2011/3/15 Tom Rini<[email protected]>:
On 03/14/2011 11:52 AM, Frans Meulenbroeks wrote:
[cut out large part of text]
Overall this seems like a fine proposal to me. Thanks a lot for drafting
it.
There are a few minor suggestions I would like to make.
First is to define which components are considered to be critical, as
for what is non-critical for one person might be critical for someone
else.
Leaving this open is bound to lead to discussion and disagreement
later on, perhaps better be clear about it upfront.
We see that as outside of the scope of this policy but I agree it needs to
be settled up, at least as a starting point sooner rather than later. So
that we don't forget, please ask us to put this on the agenda.
I agree that that is outside the policy (but within the TSC domain).
I'll bring it up when I see the agenda.
Note that I am quite busy tomorrow so it might be (my) thursday
morning before I get to that.
Thanks.
Second is the location of deprecated recipes.
As far as I know we haven't clearly defined what goes into meta-oe.
Well, that's up to OE at large, including how it's run. We're just setting
out how the core should work right now.
I understand, but as said before this is also a topic for the TSC
One more agenda topic :)
I have assumed that this is one layer that will (also) contain recipes
that are not part of oe-core.For example a recipe for a UPnP server or
a CD recording program.
Correct. We expect meta-oe to continue to hold things that are not
essential but are useful and not distribution specific.
Mixing deprecated oe-core and mainline non-core recipes in the same
tree will probably lead to confusion and perhaps even to people trying
to upgrade deprecated recipes in meta-oe.
Why? If meta-oe doesn't need something that's deprecated in the core it
shouldn't take it on. If it does need something deprecated, we should try
and figure out what can be done about that in order to fix that, or live
with it (which is to say, if package A depends on package B no newer than
version 2.0 and package B is now up to 3.2, is package A something that's
really worth keeping? Or should it perhaps go away?
Well there are two things I like to avoid.
First one is someone seeing a deprecated OE-core recipe in meta-oe.
Say this recipe is at 1.X. The person seeing this knows that upstream
is at 1.Y (Y> X), but is not aware that this recipe (and maybe 1.Y)
is in oe-core and starts to work at it.
Only later (e.g. when submitting changes) (s)he learns that actually
the newer version is in OE-core, and that all the work is wasted
timel. This is not an encouraging experience).
I think it would help if people are alerted that a newer version
exists in oe-core)
I don't see this happening as you don't use meta-oe by itself but
oe-core + meta-oe (+ possibly more).
The second one is that we have many versions of the same recipe and no
one really cares or maintains these old versions. (if they are
maintained and used I have no objections against multiple versions,
but I am somewhat allergic to recipes that are kinda orphaned and
sometimes do not even build).
Right. The default case isn't "throw it in meta-oe" when there's a new
version but "is someone volunteering to take this into meta-oe because
they need it".
Btw that raises the following question: if a distro wants to pin (for
whatever reason) a certain recipe, but that version is not really
needed by other packages or so, does it still live in meta-oe? or
should it then eventually move into a distro specific overlay? I'm
especially thinking about distro's that are not too active in updating
their pinnings
It's up to however meta-oe wants to run things. It sounds like the
desire is that if people are active and things work, it's fine to have
things in meta-oe.
In order to avoid that confusion is is probably better to give the
deprecated oe-core recipes their own layer (e.g. old-oe-core).
If something isn't needed, we don't want to have to carry it anywhere other
than in the scm history. If it's needed, it should be somewhere active so
it can be used. We can re-evaluate this at a later point in time if it's
not working, but we discussed this and that was our conclusion (that's my
recollection at least, the log can be checked over if needed).
I'm not sure if I saw the last log.
Key in your remark is what defines "needed".
Also what I often see is that things are needed, but after a while
become unneeded and become somewhat orphaned.
So, using a recent example. policykit dropped needing eggdus build.
And if we had (we didn't for various reasons) dropped the older versions
and nothing else needed eggdbus, it too should have been brought up to
the ML for removal.
But, no policy will be perfect in keeping the metadata from having no
out of date / unused recipes and I'm sure we'll still run into "tried X,
it didn't work and turns out to be real old and unmaintained."
Apart from the above I feel it would be good if the TSC would discuss
the location of OE recipes that are non-core, and also draft a
retention policy for that location.
This might of course be similar or identical to the oe-core one.
So that we don't forget, please reply to the next TSC meeting agenda (which
should be sent out sometime Wednesday, iirc) and it'll get put on the list.
will do.
Thanks again. :)
--
Tom Rini
Mentor Graphics Corporation
_______________________________________________
Openembedded-devel mailing list
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
