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
Received on Mon Aug 10 2015 - 18:38:21 UTC