> Is it trying to save space on target device, or trying to save space > on the build host? You really do need to describe your process in more > detail.
It's attempt to save space on build host. > I guess what I'm trying to object is splitting things into smaller > packages when the full set must be installed anyway. Accepting this > would open the door for further such tweaks, which just make things > more complex, without actual benefit for standard, commonly accepted > ways to handle target installation. I agree with this. Regards, Oleksiy ________________________________ From: Alexander Kanavin <alex.kana...@gmail.com> Sent: Wednesday, February 12, 2025 16:19 To: Oleksiy Obitotskyy -X (oobitots - GLOBALLOGIC INC at Cisco) <oobit...@cisco.com> Cc: Peter Kjellerstedt <peter.kjellerst...@axis.com>; Ross Burton <ross.bur...@arm.com>; openembedded-core@lists.openembedded.org <openembedded-core@lists.openembedded.org>; Ruslan Bilovol (rbilovol) <rbilo...@cisco.com> Subject: Re: [OE-core] [PATCH] systemd: move systemctl utility to separate subpackage On Wed, 12 Feb 2025 at 15:22, Oleksiy Obitotskyy -X (oobitots - GLOBALLOGIC INC at Cisco) <oobit...@cisco.com> wrote: > In practice getting rid of systemd and leaving only systemctl binary gives me approx. 20Mb disk space > > 3.0M libsystemd-shared > 960K libsystemd > 9.4M systemd > 424K libnss-systemd > > ~5 Mb could be extra dependency libraries removed after systemd removal. libsystemd-shared shouldn't be there, as it is required by systemctl. So the savings are less. Is it trying to save space on target device, or trying to save space on the build host? You really do need to describe your process in more detail. There's also a standard mechanism for adding software to targets (or making the initial target rootfilesystems): packages and package manager. You need to explain why that is not being used. > Regarding runtime dependencies - components will be merged on target and all > dependencies will be resolved. All necessary libraries will be taken from one > "base" component that will deliver whatever we need, like glibc, systemd, > etc. We have only one "base" component (or more - it depends how many > different libraries/versions we need to support). > I guess what I'm trying to object is splitting things into smaller packages when the full set must be installed anyway. Accepting this would open the door for further such tweaks, which just make things more complex, without actual benefit for standard, commonly accepted ways to handle target installation. Alex
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#211303): https://lists.openembedded.org/g/openembedded-core/message/211303 Mute This Topic: https://lists.openembedded.org/mt/111032725/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
