Re: RFC: Renaming uboot-utils

[Paul Sokolovsky <pmiscml@gmail.com>]

Hello Andy,

[cc'ed back to the list]

Monday, December 17, 2007, 4:24:21 PM, you wrote:

> Hi Paul, I appreciate the extra eyes.
>>
>>   Yeah, all this discussion became rather confusing. To understand
>> what's it all about, a careful look at the commit was required, and
>> that uncovered few botched things:
>>
>> --- packages/uboot/u-boot-utils_1.2.0.bb        64396fa43c9fcef1ed1cd3ae82a49d140febbbd0
>> +++ packages/uboot/u-boot-utils_1.2.0.bb        64396fa43c9fcef1ed1cd3ae82a49d140febbbd0
>>
>> +DEPENDS_openprotium = "mtd-utils"
>>
>>    Think again - does u-boot-utils require mtd-utils headers or tools
>> during compile-time? Moreover, is it required for openprotium only?
>>
>> +SRC_URI_append_openprotium = " \
>> +        file://fw_env.c.patch;patch=1 \
>> +        file://tools-Makefile.patch;patch=1 \
>> +        file://env-Makefile.patch;patch=1 \
>> +        file://fw_env.config"
>>
>>    What so special of these patches that they apply only to
>> openprotium?
>>
>>   
> Building fw_setenv does require mtd-utils at compile time to pick up 
> certain headers.

  Hm. Can't it be really built against just kernel headers? Pity, but
ok.

> OP is the only distro that currently needs u-boot-utils (for fw_setenv,
> a target
> utility).  I was trying to bend that out of the way: this package won't do
> anything if you aren't building OP.  But perhaps that was wrong - I should
> always built that utility, and you can use this package or not.  Is the
> latter
> way the right OE way?

  Yes, I'd say the right way for mainline OE is to use machine/distro
overrides very sparingly, in selected places only. OE provides
flexible overrides mechanism to address special needs a vendor may have
to build its product per its requirements, but such overrides better live
in vendor trees/overlays. For mainline OE, I'd say it's better to err
on generality, than create complex and non-maintainable overrides maze
(an example is OPIE which risked removal from OE due to this, and by
now has been almost completely cleared off from any
machine-specific hacks).

>> +EXTRA_OEMAKE_openprotium = "CROSS_COMPILE=${TARGET_PREFIX}"
>>
>>    Overrides above are worth privilege of doubt, but this one doesn't
>> need it: doing things like this in the OE mainline is rather incorrect
>> behavior to all other projects/users.
>>   
> Yeah, sorry - this is a remnant from the (broken) way the old package
> worked.  I should have caught that.
>> --- packages/tasks/task-base.bb 784db9539c99a3dfc0ce43cc4b61f9cd5eba3b27
>> +++ packages/tasks/task-base.bb 7a9b59f5510daa79b732e48d67445e1d5ebc4c81
>>  RDEPENDS_task-base-uboot = "\
>> -    uboot-utils"
>> +    u-boot-utils-native"
>>
>>      More attention could have been spent here too - non-native
>> package *cannot* RDEPENDS on native, this is one of abort conditions
>> in insane.bbclass. Someone who added the original line thought that
>> uboot-utils is actually what its name suggests. When you'll be fixing
>> it, don't forget about this:
>>   
> Perhaps the MACHINE|DISTRO_FEATURES uboot should just
> go away?  It was only needed to make the native mkimage program,
> which really should be a kernel DEPENDS anyway.  Sound
> reasonable?

  Let's hear Rod Whitby speak up, AFAIR, he added those features. But
as far as I understand, no, they should be there, and are the way to
add a particular bootloader support to *any* distro. Have a look at
apex and redboot support at the same place. So, if you say that your
machine has u-boot as bootloader, you'll get utils to manage it in the
image. Ditto for other bootloaders.

[]


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