Re: 'IMAGE_FEATURES' in Isar

[Claudius Heine <claudius.heine.ext@siemens.com>]

Hi Baurzhan,

On 2018-04-12 16:26, Baurzhan Ismagulov wrote:
> On Wed, Apr 11, 2018 at 02:59:38PM +0200, Claudius Heine wrote:
>> since we discussed that we might want to implement 'IMAGE_FEATURES' in Isar
>> in order to support images without kernel, I wanted to start some
>> brainstorming about what this should be used in other cases.
> 
> Why not just generate without the kernel by default, adding one (possibly via a
> virtualized name) to specific images as a dependency / IMAGE_INSTALL? IMHO,
> the logic of adding instead of removing is more in the spirit of bitbake.

I just posted an idea to solve this in a simple way, that shows how I 
would have done it.

Alex brought up the IMAGE_FEATURES idea and this thread just discuss it 
and to answer the questions: What else could IMAGE_FEATURES be used for? 
And does it make sense to use it to specify if the kernel should be part 
of the image or not?

>> While discussing that with Jan we came some ideas that would be nice to be
>> implemented as features:
>>
>>    - Cleanup steps like localepurge, and apt-get clean
> 
> Just do it always, as in your patches?

You meant the '*-configscripts.sh'?

AFAIK the purpose is to try to move most of this stuff out of there and 
into a 'system-setup-package' of sorts. At lease for all of those 
things, that don't require doing it at the end of everything.

The rest of those steps (like those cleanup commands) should be split up 
into smaller scripts each with just one task and then trigger them via 
IMAGE_FEATURES after all packages were installed. Then the difference 
between raspbian and debian might just be some different entries in the 
IMAGE_FEATURES (or DISTRO_FEATURES) variable. At least thats my current 
idea here.

>>    - Removal of apt and other possible reduction tasks
> 
> Additional recipe some images depend on?

Removal of apt and other reduction steps should be done after all 
packages are installed using apt. Doing that in some other recipe/debian 
package just doesn't work.

>> About installing the kernel: It could be possible to have some 'nokernel'
>> feature, but I am currently not sure if that is right.
>> Debians 'debootstrap' does not install a kernel per default, so if we now
>> have a kernel per opt-out we are a bit in a conflict with the
>> 'Debian-Way-Of-Life' IMO. Because there even the kernel is a opt-in package.
> 
> I agree. Specify explicitly where needed, not remove some enforced default.
> There are systems where the kernel is installed in a separate partition and
> isn't contained in the rootfs.
> 
> 
>> Of course most images created by Isar will have a kernel, so I also see that
>> reason for including one.
> 
> Not a problem with explicit addition.
> 
> 
>> The other question might be if having a kernel should be implemented as a
>> IMAGE_FEATURE or rather a setting in the machine.conf?
> 
> We already have it in IMAGE_INSTALL for isar-image-base. Doesn't it work if the
> kernel is removed from there?

This is how I do it in the current "Optional kernel" patchset.

regards,
Claudius

-- 
DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-54 Fax: (+49)-8142-66989-80 Email: ch@denx.de