--- 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/libskarnet.so -lskarnet /usr/lib/libskarnet.so: undefined reference to `clock_gettime' collect2: ld returned 1 exit status >> 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. 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: https://www.debian.org/doc/debian-policy/ch-sharedlibs.html > 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