[OE-core] [PATCH v2] util-linux: make blkdiscard a separate package

[Jussi Kukkonen]

On 29 March 2017 at 20:42, Stefan Agner <stefan at agner.ch> wrote:

> On 2017-03-29 08:41, Burton, Ross wrote:
>
>
> On 28 March 2017 at 23:45, Stefan Agner <stefan at agner.ch> wrote:
>
>> @@ -30,8 +30,8 @@ PACKAGES =+ "util-linux-agetty util-linux-fdisk
>> util-linux-cfdisk util-linux-sfd
>>               util-linux-swaponoff util-linux-losetup util-linux-umount \
>>               util-linux-mount util-linux-readprofile util-linux-uuidd \
>>               util-linux-uuidgen util-linux-lscpu util-linux-fsck.cramfs
>> util-linux-fsck \
>> -             util-linux-blkid util-linux-mkfs util-linux-mcookie
>> util-linux-reset \
>> -             util-linux-lsblk util-linux-mkfs.cramfs util-linux-fstrim \
>> +             util-linux-blkdiscard util-linux-blkid util-linux-mkfs
>> util-linux-mcookie \
>> +             util-linux-reset util-linux-lsblk util-linux-mkfs.cramfs
>> util-linux-fstrim \
>>               util-linux-partx util-linux-hwclock util-linux-mountpoint \
>>               util-linux-findfs util-linux-getopt util-linux-sulogin
>> util-linux-prlimit"
>>
>
> We're growing a lot of packages containing a single binary.  Would it be
> sensible to group them into "file system tools", "process tools", etc?
>
> Not sure if such a high level grouping is helpful. Just because an
> image uses one fs utility, does not mean the others are used too. There
> might be some potential on a lower level (e.g. util-linux-mkfs.cramfs and
> util-linux-fsck.cramfs).
>
> Is having lots of single binary packages an issue? I guess package
> management data adds some space overhead? In my case, I build a image
> without package metadata, so I guess there is no overhead for the final
> image (for the final image).
>

I have no hard data on this but we are struggling with oe-selftests taking
too long (we're talking 4-10 hour runs and personally I think we should be
running many more tests than we currently do).

The time it takes to boot an image and run the test won't be affected by
this patch, but I'm guessing it does increase the packaging and rootfs
generation time by a little bit. Multiply that by the number of images we
build and add it to all the other "little bits" of time...

Would be nice to have some hard data on this though -- I don't really know
if this is the place to optimize.

Jussi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openembedded.org/pipermail/openembedded-core/attachments/20170330/cf292313/attachment-0002.html>