On 10/08/2015 18:59, Buck Evan wrote:
I'm wrapping up my work to provide debian packages for s6.
Nice, thanks for your effort!
https://github.com/bukzor/s6-packaging/tree/dockerize
Can you please explain the reason for the patch at
https://github.com/bukzor/s6-packaging/blob/dockerize/skalibs/debian/patches/01_link_against_librt_if_necessary.patch
?
My rule of thumb is that libraries, even shared ones, should not
pull in dependencies and that everything should be done at the
executable level. When I'm writing an application that I *know*
won't need some functionality, and the linker still pulls in the
kitchen sink because the packager introduced a dependency in a
shared library I'm using, I explode in rage, and calm myself down
by devising elaborate torments for the person who introduced that
detrimental dependency, whom I affectionately dub "fucking shitty
noob packager".
This is especially true when someone pulls me a link to libpthread,
but it has happened with librt too.
I pay special attention in the skarnet.org Makefiles so that
every executable is linked with the libraries it needs, no more,
no less; -lrt happens exactly when it needs to happen. I expect
executable authors to do the same: that's what the *.lib files
in the sysdeps directory are for. There are even a few
widespread utilities to help them achieve exactly that:
pkg-config, for instance.
So, why does the $(RT_LIB) need to be there, since it will, or
should, be provided by executables that need it ?
https://github.com/bukzor/s6-packaging/blob/dockerize/skalibs/debian/rules
I would advise you to name the sysdepsdir differently from $(lib)/skalibs,
both for clarity ("skalibs" doesn't immediately tell "oh, there are sysdeps
in that directory) and for future compatibility: I can't guarantee that
there will never be anything else than a sysdeps directory to store into
/usr/lib/skalibs. So you probably should keep it as $(lib)/skalibs/sysdeps,
even if it's the only subdirectory of $(lib)/skalibs for now.
Secondarily, the way I've divided the projects into packages is specified
in the .install files. Files which are only necessary for compiling further
tools, rather than "normal usage" are relegated to -dev packages, making
six packages in all.
That's perfectly reasonable.
Is this Debian policy that /lib/*.so is in the -dev while
/lib/*.so.* is in the runtime package ? If you're developing
and want to link against the .so, you need the shared object
at compile time anyway, you can't do with just the .so symlink
(or can you ?) - so, what's the rationale for separating just
that link instead of having all the .so stuff in the runtime
package ?
Final point of order, since the "skalibs" package contains no such file,
and is in fact primarily providing a "libskarnet" file, would you be ok if
I renamed it to "libskarnet"? It's possible that downstream debian might
insist, and I want to have an answer ready.
I have no interest in distros' policies and idiosyncrasies; however,
clarity for the user is important. If Debian wants to rename the package
to fit whatever rule they pulled out of their a^Hhats this year, I have no
objection as long as there is something, anything, in the package database
that yields a pointer to the correct package when a user looks for
"skalibs".
Thanks again!
--
Laurent
