On 6/26/20 3:52 AM, Ross Burton wrote:
On Thu, 25 Jun 2020 at 11:14, Fredrik Gustafsson
<fredrik.gustafs...@axis.com> wrote:
Poky today has three different package managers, the well-known formats deb
and rpm is supported as well as ipkg that is good for embedded devices.
When building and having a good cache hit, a significant amount of time is
spent in the phase of generating a rootfs, which is really about the
performance of the package manager. ipkg is way slower than deb or rpm. To
save build time and also get a package manager that is suitanle for use on
targets where flash memory is a concern, support for apk is suggested.
However, it might or might not be what's wanted for Poky since it increases
the test matrix. Therefore this patch series refactors the package
management code so that it's possible to add more package managers in other
own layer. I will send another patch serie that will add apk.
As to the code review I mostly second what Paul said.
However, obviously you actually have strong feelings on this as the
series represents a fair amount of work. What are the compelling
reasons to use apk? Five seconds on core-image-minimal doesn't really
sell it to me, I don't think anyone ever claimed that opkg has been
performance optimised, dpkg isn't really used that much: maybe we
should re-evaluate what package managers are supported if apk has
feature parity but is significantly faster or has other advantages.
25% is a lot, real world images are way more complex than reference
images in reference distribution, we have images which use 7 to 10 mins
in rootfs, I have seen a desire by many developers in optimizing build
time so this could be a real help, especially where we dont care about
package management at runtime, we have done many micro optimizations and
rejected patches since they added to build time because we want to be
sensitive for increasing build time. rootfs is one task where sstate
caching does not help as well, while other package builds we can benefit
from sstate, rootfs not so much hence such an optimizations, if we test
it regularly perhaps can be debated, but it certainly seems interesting
option to have.
Ross
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#140138):
https://lists.openembedded.org/g/openembedded-core/message/140138
Mute This Topic: https://lists.openembedded.org/mt/75057633/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
