Comment 11 for bug 2009495

------- Comment From <email address hidden> 2023-03-17 21:01 EDT-------
(In reply to comment #15)
> The purpose of the /usr/lib/s390x-linux-gnu directory is to make libraries
> for multiple architectures co-installable on the same filesystem (multiarch).
>
> If you're going to create a symlink from /usr/lib, and the package in
> question can't be co-installable because it also ships files in /usr/bin,
> and the programs that use it only access it via the /usr/lib/ path instead
> of the /usr/lib/s390x-linux-gnu path *anyway*, then it's useless to install
> the library in /usr/lib/s390x-linux-gnu at all. Instead of adding a link,
> you should *move* the file at build-time to the /usr/lib directory where it
> will be looked for.
>
> Also, the filename ("preload") implies this isn't actually a shared library
> that programs will link against, but that they preload/dlopen it instead.
> For such cases, it's preferred that the library be shipped in a per-project
> subdirectory of /usr/lib. See libfakeroot for an example of this. This is
> not a blocker for SRU, just a comment on best-practices here.
>
> The first issue, however, is an SRU reject for me. If we're going to touch
> this in an SRU, then we should do it the right way, not with extraneous
> extra symlinks.
>
> An upload of smc-tools to kinetic-proposed has been rejected from the upload
> queue for the following reason: "Per comments on bug report".

Regarding the second point, AFAIU the smc_run is just a convenience wrapper,
and it is a documented than one can also "smc-fy" applications (that are not installed as a part of the smc-tools package) by invoking them like this:
#LD_PRELOAD=libsmc-preload.so <application_start_cmd>
(for reference have a look at https://www.ibm.com/docs/en/linux-on-systems?topic=sps-setup-4).

My guess is that the application needs to be a 64-bit one although the aforementioned documentation does not seem to care to state it.

In any case, I don't think we would be happy with some "per project subdirectory of /usr/lib" because of that piece of documentation.

Regarding the first part, I don't quite understand enough. I'm quite confused actually. AFAIU for supporting the "smcifying" both 64 and 31 bit programs, we would have to provide both an 64 and a 31 bit version of libsmc-preload.so. Is that right?

If that is right, my guess is that the 64 bit variant would go under
/usr/lib/s390x-linux-gnu
and the 31 bit variant would go under
/usr/lib/s390-linux-gnu
and I hope ld.so would pick up the "right one". Does that sound about right? It does not mesh well with this has to go under /usr/lib idea, so I guess there is somewhere a mistake in my train of thought. Can you help me to figure it out?

Regards,
Halil