[oe] pfalcon: revert r5dc6982e... vfat nls modules are not for task-base-kernel26

[Rod Whitby]

Paul Sokolovsky wrote:
> Tuesday, December 18, 2007, 3:08:23 AM, you wrote:
>> 10k that is not required, and is forcibly imposed, is a bloat.
>> task-base has a fine granularity for a reason (in fact, that is the very
>> reason it was created).  You are violating that fine granularity, and
>> imposing your choice on others without allowing them to 'opt-in' via a
>> feature.
> 
>   Nonsense. The change I made has nothing to do with forcing or
> disallowing. It is a quick fix, similar to other fixes applied to
> task-base/its overall state, to fix current issue at hand, and yet
> be a small incremental step in the right direction (moving
> machine-independent modules out of machine configs into task-base).
> And it was done is such a way to not cause any noticeable regressions.
> For example, there's no size-optimized image which stopped fitting
> into size constraint set for it.

This is a discussion about the principles of task-base, not about a
quick fix.  If your position is indeed that this is a quick fix, and
that you intend to move it into a task-base-vfat at your (or someone
else's) earliest convenience, then I have no problem with that.  It
seemed, however, that you have been strongly arguing about the
principles of task-base, and that is the point to which I take issue.
If you had said "mea culpa, I agree with the principle, I'll fix it next
week", then we could have avoided this exchange completely.

>   Just face it - my change was on par with current state of task-base.

I don't agree with that.  I observe that task-base has been carefully
crafted, and I believe the OE developers have been vigilent in making
sure that the basic tasks (like task-boot and task-base-kernel26) are
not bloated.

>   Oh, so you caught me on one supposedly questionable change, and I
> point out numerous other highly related issues of the same nature, and
> invite you address them as we already started on that. Instead, you
> tell that you don't care and think it's normal if some machines will
> lose the feature they must have. That doesn't sound too productive.

Actually, I do care very much.  I care that those things are done in the
proper manner.  The machines didn't have the feature by omission.  You
added it in the wrong place.  Correcting that by adding it in the right
place will enable those machines to retain that feature, not loose it.
Getting it in the right place is more important than a day's delay on an
Angstrom RC release.

>   I'm trying to do my share of release management here, and thus care
> about all machines, and facing a dilemma of need to fix dozen machine
> quickly while risking to nudge few a tiny bit sideways, I select to do
> that, in grounded manner. So, I'd like to ask you to be patient with
> such changes, until the real fix is introduced, if it happens that you
> cannot be helpful with that (== the real fix, not some small untested
> patch).

If you agree that those nls modules should not be added to
task-base-kernel26, since that violates the principle of fine
granularity of task-base, and that they will be moved to a feature at
someone's (perhaps your's, perhaps mine, perhaps hrw's) earliest
convenience, then we have no quarrel.  I have no issue if the earliest
convenience takes weeks - it's the principle of how task-base evolves in
the future which is my primary concern here.

-- Rod