[LU-5104] Split binaries across packages more smart

• Type: Technical task
• Resolution: Fixed
• Priority: Minor
• Fix Version/s: Lustre 2.7.0
• Assignee: Dmitry Eremin (Inactive)
• Reporter: Dmitry Eremin (Inactive)

Description

Binaries and scripts used only for debugging purposes are now into the main Lustre package. It may confuse new users and waste of disk space. Also some scripts brings additional dependency from perl package. This can be critical for small or embedded systems where only Lustre client is going to be installed and perl is not a part of default installation.

The proposal is to split main package into at least two different packages. The first package should contain minimal set of tools really required for Lustre support. The second one can contain the rest of binaries and scripts.

Issue Links

• is related to: LU-3957 Create separate server and client binary rpms from one build

Comments

[Bruno Faccini (Inactive)]

I wrongly suspected this ticket to cause some incmpatibilities, resolving again, sorry.

[Bruno Faccini (Inactive)]

Gerrit change #10654 for this ticket breaks LU-1032/LU-5465 creation of Lustre Server DKMS RPMs, because now mount_osd_[zfs,ldiskfs].so lib is part of lustre-osd-[zfs,ldiskfs] binary RPM but is not part/built of/by DKMS RPM.
We need to find a way to fix this, or this will lead to Lustre DKMS Server modules RPM to be unusable, at least for IEEL deployments ...

[Dmitry Eremin (Inactive)]

Patch landed to master.

[Christopher Morrone (Inactive)]

Great. Thanks for comments. Is it Ok to have the following list of files in client package?

Many of those commands should be installed on both client and servers nodes, e.g. lfs, lctl. At the very lest, these should only be installed as part of a server specific package:

• /usr/sbin/ll_decode_filter_fid
• /usr/sbin/lshowmount (although this is likely to be removed altogether under http://review.whamcloud.com/10510/)
• /etc/ldev.conf
• /etc/udev/rules.d/99-lustre.rules
• /usr/sbin/ldev

[Christopher Morrone (Inactive)]

There could certainly be some overlap, but they are mostly distinct issues. This ticket deals with moving binaries mostly among the existing sub-packages. LU-3947 would create a new sub-package altogether. To my knowledge, no one is currently working on LU-3947, so the risk of conflicts is low.