[OE-core] [PATCH 2/2] rootfs_rpm.bbclass: don't remove rpmlib when INC_RPM_IMAGE_GEN=1

Robert Yang liezhi.yang at windriver.com
Sat May 12 09:40:41 UTC 2012



On 05/12/2012 12:54 AM, Saul Wold wrote:
> On 05/09/2012 07:13 PM, Robert Yang wrote:
>>
>>
>> On 05/09/2012 11:24 PM, Koen Kooi wrote:
>>>
>>> Op 9 mei 2012, om 17:15 heeft Mark Hatle het volgende geschreven:
>>>
>>>> On 5/9/12 10:01 AM, Koen Kooi wrote:
>>>>>
>>>>> Op 9 mei 2012, om 16:52 heeft Mark Hatle het volgende geschreven:
>>>>>
>>>>>> On 5/9/12 3:50 AM, Koen Kooi wrote:
>>>>>>>
>>>>>>> Op 9 mei 2012, om 10:20 heeft Robert Yang het volgende geschreven:
>>>>>>>
>>>>>>>> Don't remove rpmlib when INC_RPM_IMAGE_GEN=1, otherwise the
>>>>>>>> list_installed_packages would get nothing in the second build.
>>>>>>>
>>>>>>> What happens when I do a build, enable INC_RPM_IMAGE_GEN and do
>>>>>>> another build?
>>>>>>
>>>>>> The intention is that only the packages that have been
>>>>>> changed/upgraded will be installed. Instead of the whole image
>>>>>> being generated from scratch each time.
>>>>>
>>>>> That's what INC_RPM_IMAGE_GEN does, yes. What I'm asking is how this
>>>>> patch addresses the sequence I outlined above.
>>>>
>>>> Explain what you mean by "build".
>>>>
>>>> Using the following:
>>>>
>>>> . ./oe-init-build-env build-test
>>>> <setup local.conf w/ rpm packaging and INC_RPM_IMAGE_GEN>
>>>> bitbake core-image-core
>>>> --- time passes, git pull pulls in changes ---
>>>> bitbake core-image-core
>>>>
>>>> The second "build", only the changed packages will be added to the
>>>> image.
>>>>
>>>> You you are using different build directories, then it doesn't re-use
>>>> anything. The purpose of this is incremental software development
>>>> within a single build directory.
>>>
>>> You are still missing my point. The patch is broken if you change
>>> INC_RPM_IMAGE_GEN
>>
>> Only the core-image-minimal has this problem, other images won't remove the
>> database, the core-image-minimal removes the database to save disk space (
>> only saves quite a little), and I don't know whether there is a better
>> solution
>> for the core-image-minimal, maybe move the database to ${T} rather than
>> remove
>> it, and move it back to the rootfs directory at the early stage of
>> do_rootfs, but I don't know whether this is worth or not since this is
>> just used for
>> saving the time at the development stage, as it had told:
>>
> Robert,
>
> The move might be the best solution since it will preserve it and make the
> behavior more predictable, ie if one starts with INC_RPM_IMAGE_GEN disabled and
> then enables it the package database will be available already. It would also
> preserve the space in the core-image-minimal by not keeping those database files
> in the image.
>

Thanks Saul, I will send a V2 for it.

// Robert

> Please respin this patch.
>
> Thanks
> Sau!
>
>
>
>> # Incremental rpm image generation, the rootfs would be totally removed
>> # and re-created in the second generation by default, but with
>> # INC_RPM_IMAGE_GEN = "1", the rpm based rootfs would be kept, and will
>> # do update(remove/add some pkgs) on it. NOTE: This is not suggested
>> # when you want to create a productive rootfs
>>
>> // Robert
>>
>>> _______________________________________________
>>> Openembedded-core mailing list
>>> Openembedded-core at lists.openembedded.org
>>> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
>>>
>>
>> _______________________________________________
>> Openembedded-core mailing list
>> Openembedded-core at lists.openembedded.org
>> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
>>
>>
>




More information about the Openembedded-core mailing list