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

Stefan Agner stefan at agner.ch
Wed Mar 29 17:42:49 UTC 2017


 

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). 

Best regards, 

Stefan 
  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openembedded.org/pipermail/openembedded-core/attachments/20170329/0a9f3acb/attachment-0002.html>


More information about the Openembedded-core mailing list