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

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

[Rod Whitby]

<CIA-34> pfalcon org.oe.dev * r5dc6982e... / (1
packages/tasks/task-base.bb):
<CIA-34> task-base: Add NLS modules for VFAT support.
<CIA-34> * Add to task-base-kernel26, as vfat is pretty basic feature.
<CIA-34> Worth refactoring to vfat feature still, I guess.

You guessed right.

kernel26 is not a kitchen sink where you can just add vfat-related nls
modules that are not strictly required for booting a 2.6 kernel.

Your addition has just *bloated* the rootfs for *every* 2.6 machine,
including those that have no possible way of ever mounting an external
memory stick at all, let alone a vfat-formatted one.

vfat is *not* a basic feature that should be enabled for all 2.6 kernel
machines.  If you want vfat nls modules, then create a vfat feature
(just like there is an ext2 feature).  Do not pollute the basic kernel26
feature with this stuff.

And the comment about "# If you don't need VFAT support - don't enable
them in defconfig." is not applicable, because there are machines that
want vfat-related nls modules available in the feed as a downloadable
package, but not in the initial rootfs.  Therefore they need to be in
the defconfig, but certainly should not be in task-base-kernel26.

I expect you to revert this change and do it properly, or not do it at all.

-- Rod

Re: pfalcon: revert r5dc6982e... vfat nls modules are not for task-base-kernel26

[Rod Whitby]

Rod Whitby wrote:
> I expect you to revert this change and do it properly, or not do it at all.

Here's an untested example patch to get you started.  You'll probably
want to change the comments before applying something similar.  Note
again that it is untested - that's your job, not mine.

> #
> # old_revision [bc668ae9f53d5e7dbaeee92daced9790f1be61e0]
> #
> # patch "packages/tasks/task-base.bb"
> #  from [f33c49fb3e3820bd151a0e0035b125643a46b85a]
> #    to [643465073bdf81ce0f09fb63480d026b4c6f3e28]
> #
> ============================================================
> --- packages/tasks/task-base.bb f33c49fb3e3820bd151a0e0035b125643a46b85a
> +++ packages/tasks/task-base.bb 643465073bdf81ce0f09fb63480d026b4c6f3e28
> @@ -15,6 +15,7 @@ PACKAGES = ' \
>              ${@base_contains("MACHINE_FEATURES", "alsa", "task-base-alsa", "", d)} \
>              ${@base_contains("MACHINE_FEATURES", "apm", "task-base-apm", "", d)} \
>              ${@base_contains("MACHINE_FEATURES", "ext2", "task-base-ext2", "", d)} \
> +            ${@base_contains("MACHINE_FEATURES", "vfat", "task-base-vfat", "", d)} \
>              ${@base_contains("MACHINE_FEATURES", "irda", "task-base-irda", "",d)} \
>              ${@base_contains("MACHINE_FEATURES", "keyboard", "task-base-keyboard", "", d)} \
>              ${@base_contains("MACHINE_FEATURES", "pci", "task-base-pci", "",d)} \
> @@ -87,6 +88,7 @@ RDEPENDS_task-base = "\
>      \
>      ${@base_contains('COMBINED_FEATURES', 'alsa', 'task-base-alsa', '',d)} \
>      ${@base_contains('COMBINED_FEATURES', 'ext2', 'task-base-ext2', '',d)} \
> +    ${@base_contains('COMBINED_FEATURES', 'vfat', 'task-base-vfat', '',d)} \
>      ${@base_contains('COMBINED_FEATURES', 'irda', 'task-base-irda', '',d)} \
>      ${@base_contains('COMBINED_FEATURES', 'pci', 'task-base-pci', '',d)} \
>      ${@base_contains('COMBINED_FEATURES', 'pcmcia', 'task-base-pcmcia', '',d)} \
> @@ -159,14 +161,7 @@ RRECOMMENDS_task-base-kernel24 = "\
>      kernel-module-input \
>      kernel-module-uinput"
> 
> -# utf8 - Standard FS encoding
> -# iso8859-1, cp437 - These 2 are default encodings used by VFAT
> -# If you don't need VFAT support - don't enable them in defconfig.
> -# If you build them, you want VFAT support and they're included by default.
>  RRECOMMENDS_task-base-kernel26 = "\
> -    kernel-module-nls-utf8 \
> -    kernel-module-nls-iso8859-1 \
> -    kernel-module-nls-cp437 \
>      kernel-module-input \
>      kernel-module-uinput \
>      kernel-module-rtc-dev \
> @@ -194,6 +189,15 @@ RDEPENDS_task-base-ext2 = "\
>      e2fsprogs-e2fsck \
>      e2fsprogs-mke2fs"
> 
> +# utf8 - Standard FS encoding
> +# iso8859-1, cp437 - These 2 are default encodings used by VFAT
> +# If you don't need VFAT support - don't enable them in defconfig.
> +# If you build them, you want VFAT support and they're included by default.
> +RRECOMMENDS_task-base-vfat = "\
> +    kernel-module-nls-utf8 \
> +    kernel-module-nls-iso8859-1 \
> +    kernel-module-nls-cp437"
> +
>  RDEPENDS_task-base-alsa = "\
>      alsa-utils-alsactl \
>      alsa-utils-alsamixer"

-- Rod

Re: pfalcon: revert r5dc6982e... vfat nls modules are not for task-base-kernel26

[Paul Sokolovsky]

Hello Rod,

Tuesday, December 18, 2007, 2:24:06 AM, you wrote:

> <CIA-34> pfalcon org.oe.dev * r5dc6982e... / (1
> packages/tasks/task-base.bb):
> <CIA-34> task-base: Add NLS modules for VFAT support.
> <CIA-34> * Add to task-base-kernel26, as vfat is pretty basic feature.
> <CIA-34> Worth refactoring to vfat feature still, I guess.

> You guessed right.

> kernel26 is not a kitchen sink where you can just add vfat-related nls
> modules that are not strictly required for booting a 2.6 kernel.

  As you perfectly know, defining what is strictly required is yet
long task to do for OE and specific machine in it. Whereas Angstrom
RCs are something to do right now.

> Your addition has just *bloated* the rootfs for *every* 2.6 machine,

  No, it did not. It just added 10k of uncompressed modules.

> including those that have no possible way of ever mounting an external
> memory stick at all, let alone a vfat-formatted one.

> vfat is *not* a basic feature that should be enabled for all 2.6 kernel
> machines.  If you want vfat nls modules, then create a vfat feature
> (just like there is an ext2 feature).  Do not pollute the basic kernel26
> feature with this stuff.

  Yeah, I have hundreds of other items on my list too ;-).

> And the comment about "# If you don't need VFAT support - don't enable
> them in defconfig." is not applicable, because there are machines that
> want vfat-related nls modules available in the feed as a downloadable
> package, but not in the initial rootfs.  Therefore they need to be in
> the defconfig, but certainly should not be in task-base-kernel26.

  Again, lots of things need to be, etc. But for now (as is), my doing it
right won't help any machine except some small nslu2. Because vfat of
course will be a distro feature, and so far 1) only nslu overrides
angstrom's DISTRO_FEATURES. Also, there're following things to
consider:

2) It's unclear if vfat feature should ship only 40-50K of kernel
modules, or truly bloat it with dosfsutils. Maybe fdisk?
3) There's also need to clear off machine configs from this stuff,
including proverbial fic-gta*.conf.


  So, I'm actually glad that you care about such stuff. So, while I
planned to do all stuff above via RFCs over following Angstrom RCs,
I'd be glad to just do another quick fix now as you request and
offload tasks 1-3 above to you. How that sounds?


> I expect you to revert this change and do it properly, or not do it at all.

> -- Rod


-- 
Best regards,
 Paul                            mailto:pmiscml@gmail.com

Re: pfalcon: revert r5dc6982e... vfat nls modules are not for task-base-kernel26

[Paul Sokolovsky]

Hello Paul,

Tuesday, December 18, 2007, 2:50:52 AM, you wrote:

[]

>> And the comment about "# If you don't need VFAT support - don't enable
>> them in defconfig." is not applicable, because there are machines that
>> want vfat-related nls modules available in the feed as a downloadable
>> package, but not in the initial rootfs.  Therefore they need to be in
>> the defconfig, but certainly should not be in task-base-kernel26.

>   Again, lots of things need to be, etc. But for now (as is), my doing it
> right won't help any machine except some small nslu2. Because vfat of
> course will be a distro feature,

  Ah no, it would be combined feature. Worse then, as it opens pandora
box of updating all machine configs with it...

[]


-- 
Best regards,
 Paul                            mailto:pmiscml@gmail.com

Re: pfalcon: revert r5dc6982e... vfat nls modules are not for task-base-kernel26

[Rod Whitby]

Paul Sokolovsky wrote:
> Tuesday, December 18, 2007, 2:24:06 AM, you wrote:
>> kernel26 is not a kitchen sink where you can just add vfat-related nls
>> modules that are not strictly required for booting a 2.6 kernel.
> 
>   As you perfectly know, defining what is strictly required is yet
> long task to do for OE and specific machine in it. Whereas Angstrom
> RCs are something to do right now.

Are you seriously putting forward the position that vfat nls modules
should be part of the basic kernel26 task, even when you yourself put a
comment in the file saying that it should be in a separate feature?

Angstrom RCs are not a license to violate basic task separation principles.

>> Your addition has just *bloated* the rootfs for *every* 2.6 machine,
> 
>   No, it did not. It just added 10k of uncompressed modules.

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.

>> vfat is *not* a basic feature that should be enabled for all 2.6 kernel
>> machines.  If you want vfat nls modules, then create a vfat feature
>> (just like there is an ext2 feature).  Do not pollute the basic kernel26
>> feature with this stuff.
> 
>   Yeah, I have hundreds of other items on my list too ;-).

The length of your todo list is immaterial to committing correct changes
to task-base.

>> And the comment about "# If you don't need VFAT support - don't enable
>> them in defconfig." is not applicable, because there are machines that
>> want vfat-related nls modules available in the feed as a downloadable
>> package, but not in the initial rootfs.  Therefore they need to be in
>> the defconfig, but certainly should not be in task-base-kernel26.
> 
>   Again, lots of things need to be, etc. But for now (as is), my doing it
> right won't help any machine except some small nslu2.

nslu2 is irrelevant here.  This is a violation of the basic principle
upon which task-base was created.

> Because vfat of
> course will be a distro feature, and so far 1) only nslu overrides
> angstrom's DISTRO_FEATURES. Also, there're following things to
> consider:
> 
> 2) It's unclear if vfat feature should ship only 40-50K of kernel
> modules, or truly bloat it with dosfsutils. Maybe fdisk?

If that is the case, then those things can be incrementally added to
task-base-vfat, without impacting machines that do not enable
task-base-vfat.

> 3) There's also need to clear off machine configs from this stuff,
> including proverbial fic-gta*.conf.

Yes, and those machines that want to take advantage of vfat nls modules
can enable the vfat feature.  And those machines that do not want to
take advantage of the feature are not *forced* *without* *choice* to
include those things in the rootfs.

>   So, I'm actually glad that you care about such stuff. So, while I
> planned to do all stuff above via RFCs over following Angstrom RCs,

Sorry, but Angstrom RCs are not a license to violate basic task-base
principles.

> I'd be glad to just do another quick fix now as you request and
> offload tasks 1-3 above to you. How that sounds?

Well, I've already sent you an example patch (it's not correct, nor
complete, so don't commit it as-is).  For #1 and #3 it's up to each
distro or machine maintainer to make the conscious choice to enable this
new feature.  For #2, that's something that is done incrementally by
each person who requires another package to be added to task-base-vfat.
 If these things are done properly, then tasks can be done incrementally
without impacting other distros and machines.

If you instead want to put in a quick fix for a particular machine or
distro, then use a machine and distro override.  Do *not* pollute all
machines or distros that use task-base by violating the basic principles
of the task-base package.

-- Rod

Re: pfalcon: revert r5dc6982e... vfat nls modules are not for task-base-kernel26

[Paul Sokolovsky]

Hello Rod,

Tuesday, December 18, 2007, 3:08:23 AM, you wrote:

> Paul Sokolovsky wrote:
>> Tuesday, December 18, 2007, 2:24:06 AM, you wrote:
>>> kernel26 is not a kitchen sink where you can just add vfat-related nls
>>> modules that are not strictly required for booting a 2.6 kernel.
>> 
>>   As you perfectly know, defining what is strictly required is yet
>> long task to do for OE and specific machine in it. Whereas Angstrom
>> RCs are something to do right now.

> Are you seriously putting forward the position that vfat nls modules
> should be part of the basic kernel26 task, even when you yourself put a
> comment in the file saying that it should be in a separate feature?

  No, I'm hinting that release management is a subtle task, requiring
compromises and serialization.

> Angstrom RCs are not a license to violate basic task separation principles.

>>> Your addition has just *bloated* the rootfs for *every* 2.6 machine,
>> 
>>   No, it did not. It just added 10k of uncompressed modules.

> 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.

[]

> The length of your todo list is immaterial to committing correct changes
> to task-base.

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

[]

>> I'd be glad to just do another quick fix now as you request and
>> offload tasks 1-3 above to you. How that sounds?

> Well, I've already sent you an example patch (it's not correct, nor
> complete, so don't commit it as-is).  For #1 and #3 it's up to each
> distro or machine maintainer to make the conscious choice to enable this
> new feature.  For #2, that's something that is done incrementally by
> each person who requires another package to be added to task-base-vfat.
>  If these things are done properly, then tasks can be done incrementally
> without impacting other distros and machines.

> If you instead want to put in a quick fix for a particular machine or
> distro, then use a machine and distro override.  Do *not* pollute all
> machines or distros that use task-base by violating the basic principles
> of the task-base package.

  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.

  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).

> -- Rod


-- 
Best regards,
 Paul                            mailto:pmiscml@gmail.com

Re: 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

Re: pfalcon: revert r5dc6982e... vfat nls modules are not for task-base-kernel26

[Paul Sokolovsky]

Hello Rod,

Tuesday, December 18, 2007, 4:08:51 AM, you wrote:

> 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.

  Then it's wrong time and approach. I pretty well understand
task-base principles, and am all for it. Vice versa, I'm concerned
that it's heavily underused and ignored still, with machine configs
stuffed with the modules which has little to do with the machine per
se, and rather are/should be handled by task-base.

>   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.

  Design and actual implementation/maintenance are different things.
Getting it right is incremental asymptotic process, and not even
monotonic oftentimes. It would rather make sense to bulk-migrate as much as
possible content from older, highly non-scalable way to handle
features (machine configs) to task-base, and only then to clean it up
and optimize, than do complex, error-prone changes for each small feature.

>>   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.

  Yeah, except that we had such one-day delays for around half-year
per my calendar, so I personally treat release as a priority.
Especially if we have today testers which may simply disappear
tomorrow mumbling something about completely broken stuff ;-).

>>   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.

  I hope the future is bright. And the change you requested is
committed.

> -- Rod


-- 
Best regards,
 Paul                            mailto:pmiscml@gmail.com