Re: [s6] debian packaging

From: Buck Evan <>
Date: Tue, 11 Aug 2015 10:50:43 -0700

On Mon, Aug 10, 2015 at 11:38 AM, Laurent Bercot <> wrote:

> 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!
> Can you please explain the reason for the patch at
> ?
I only recall that "things were broken" when I tried to remove it.
There was a "undefined symbol" error pointing to an librt symbol.
I'll bring more specifics soon.

Without the patch, I get this during the build, on Ubuntu lucid (a severely
defunct platform, but one that's important to me):
exec gcc -iquote src/include-local -Isrc/include -D_POSIX_C_SOURCE=200809L
-D_XOPEN_SOURCE=700 -O2  -Werror=implicit-function-declaration
-Werror=implicit-int -Werror=pointer-sign -Werror=pointer-arith  -g -O2
-std=c99 -fomit-frame-pointer -fno-exceptions -fno-unwind-tables
-fno-asynchronous-unwind-tables -Wa,--noexecstack -fno-stack-protector
-pipe -Wall -c -o src/execline/wait.o src/execline/wait.c
exec gcc -o exit -g -O2 -std=c99 -fomit-frame-pointer -fno-exceptions
-fno-unwind-tables -fno-asynchronous-unwind-tables -Wa,--noexecstack
-fno-stack-protector -pipe -Wall -Wl,-Bsymbolic-functions
-Wl,--hash-style=both  -L/usr/lib/skalibs  -L/usr/lib  src/execline/exit.o
/usr/lib/   -lskarnet
/usr/lib/ undefined reference to `clock_gettime'
collect2: ld returned 1 exit status
>  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.
Roger. Easily done. Thanks.
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 ?
Yes. It's quite explicit.
Not that you care, but this is the reference:
>  The SONAME symlink is installed by the runtime shared library package,
and the bare .so symlink is installed in the development package since it's
only used when linking binaries or shared libraries. However, there are
some exceptions for unusual shared libraries or for shared libraries that
are also loaded as dynamic modules by other programs.
> 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 ?
As you say, you want the .so if you're developing.
If you're "just a user" though, none of your binaries will link directly to
that symlink.
That's the rule of thumb for moving things to the -dev package.
Possibly the bit you're missing is that x-dev almost always depends on x.
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".
Here's a Homepage: field that I'll make sure is set properly.
I'll put you down for a -0 vote on that one?
Received on Tue Aug 11 2015 - 17:50:43 UTC

This archive was generated by hypermail 2.3.0 : Sun May 09 2021 - 19:44:19 UTC