Mailinglist Archive: opensuse-packaging (104 mails)

< Previous Next >
Re: [opensuse-packaging] Splitting up binary packages for large SDKs
Hi,

On Tue, 7 Aug 2018, Jan Engelhardt wrote:

So all .so files into a -libs package. Pragmatic, but you will have
problems getting this into Factory. If you'd consider putting all the
shared libs into one (versioned) subdirectory of /usr/lib64 (and make
similar adjustments to the SDKs build wrappers for library search
paths; for shared libs you also need the RPATH) you'd avoid all
problems the shared library policy poses to you _and_ would solve the
update-libraries problem as well, at least somewhat.

RPM dependency autotracking uses only the file's basename and the file's
content. If you solely rely on a directory to have a version number, you
will almost certainly have the same ABI problems as without the extra
directory.

All true about RPM deps, they can't be solved this way (but see below).
That's the "somewhat" in my remark :) (Depending on your point of view it
might translate to "not very much", but at least it'd be possible to
install multiple such sets of libs in parallel; the dependence tracking
wouldn't at least not get in the way, it won't see a problem, and the
dependency on the version could be expressed explicitely without autodeps
on shared libs).

The only time versions in directory names are useful is when you dlopen
libraries so placed. But DT_SONAME (the things you see with `ldd`; the
things rpm sees) work without directories.

That's not fully correct. non-standard libs aren't search by default, so
will either need LD_LIBRARY_NAME, or (which was my suggestion) a
DT_RUNPATH entry in the apps, which is the point at which versioned
directories make sense again, because DT_RUNPATH will contain that version
and hence apps will only run when the correct set is installed. We could
even extend the rpm AutoReqProv mechanism to look at DT_RPATH/DT_RUNPATH
and create a Requires on, say, "libpath(/usr/lib64/foobar3)", which could
be Provided by the respective package (and even that could be AutoProvided
when a package contains shared libs in a non-standard subdir).

The whole reason we created the shared lib policy was to be able to
install multiple versions in parallel (so as to not loose old ones on
partly updates). The above versioned-directory solution would still
give this. Both approaches need a bit manual work (shared lib policy:
putting each lib into separate package; version-dir: putting libs there
and ensure that libs therein are found at linkedit- and run-time, which
is more work, but still).


Ciao,
Michael.
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe@xxxxxxxxxxxx
To contact the owner, e-mail: opensuse-packaging+owner@xxxxxxxxxxxx

< Previous Next >
Follow Ups