Debian packaging broken / building debian packages on Travis CI

[kzeslaf]

Hi,

it seems that current version of Debian packaging is broken. It seems that last changes on file https://github.com/SOCI/soci/blob/master/src/CMakeLists.txt made impossible to apply this patch: https://github.com/SOCI/soci-pkg/blob/master/debian/patches/library_target.

I think that functionality of this patch should be applied directly to this CMakeLists file because current solution is not resistant on changes of this file.

Maybe you could also configure building debian packages by Travis CI after changes to soci and soci-pkg repos.

I don't know unfortunately how to do this nicely. Maybe git submodules will do?

P.S.
I'm using Ubuntu 12.04 64-bit. Deleting patch directory was enough to build, install and run example using soci correctly.

[mloskot]

I think this is the troublemaker commit SOCI/soci@c18cf358 submitted by @vnaydionov

@kzeslaf so, you're proposing to merge @akashihi patch with current src/CMakeLists.txt, in such way that both Debian, Ubuntu and others are handled correctly, right?

I'm not experienced with .deb system as maintainer, I wonder, why are we handling Debian and Ubuntu differently now:

if(UBUNTU)
  set(SOCI_LIBDIR "lib")
elseif(DEBIAN)
  execute_process(COMMAND uname -m
                  OUTPUT_VARIABLE SOCI_ARCH
                  OUTPUT_STRIP_TRAILING_WHITESPACE)
  set(SOCI_LIBDIR "lib/${SOCI_ARCH}-linux-gnu")
elseif(APPLE OR CMAKE_SIZEOF_VOID_P EQUAL 4)
  set(SOCI_LIBDIR "lib")
else()
  set(SOCI_LIBDIR "lib64")
endif()

I really like the idea of triggering builds for SOCI/soci-pkg after changes in SOCI/soci. Task added #2

[kzeslaf]

@kzeslaf so, you're proposing to merge @akashihi patch with current src/CMakeLists.txt,
in such way that both Debian, Ubuntu and others are handled correctly, right?

Yes.

I'm not experienced with .deb system as maintainer, I wonder,
why are we handling Debian and Ubuntu differently now...

Unfortunately I don't have sufficient experience in this field either. There are always "more important tasks" than getting proper packaging knowledge.

[juliantaylor]

for upstream just continue installing into usr/lib, the debian/ubuntu multiarch thing is for now specific for packages, there is no real reason to use in an automatic fashion it outside of packaging.
People wanting to cross compile without packages can override the prefix/libdir themselves.

the package should override LIBDIR to the multiarch paths to allow multiple architecture packages to be coinstallable.
my debian package just does this with this line in (the dh-7 styles) debian/rules without the need for a patch to CMakeList.txt:

DEB_HOST_MULTIARCH ?= $(shell dpkg-architecture -qDEB_HOST_MULTIARCH)
override_dh_auto_configure:
    dh_auto_configure -- -DLIBDIR=/usr/lib/$(DEB_HOST_MULTIARCH) ...

I haven't tried it with current soci head, but it should still work

[vnaydionov]

19.02.2013, 02:07, "Mateusz Loskot" notifications@github.com:

I think this is the troublemaker commit SOCI/soci@c18cf35 submitted by @vnaydionov

@kzeslaf so, you're proposing to merge @akashihi patch with current src/CMakeLists.txt, in such way that both Debian, Ubuntu and others are handled correctly, right?

I'm not experienced with .deb system as maintainer, I wonder, why are we handling Debian and Ubuntu differently now:

if(UBUNTU) set(SOCI_LIBDIR "lib") elseif(DEBIAN) execute_process(COMMAND uname -m OUTPUT_VARIABLE SOCI_ARCH OUTPUT_STRIP_TRAILING_WHITESPACE) set(SOCI_LIBDIR "lib/${SOCI_ARCH}-linux-gnu") elseif(APPLE OR CMAKE_SIZEOF_VOID_P EQUAL 4) set(SOCI_LIBDIR "lib") else() set(SOCI_LIBDIR "lib64") endif()

Yes, it seems that I broke some packaging-related stuff.
The dirty hack was meant to help build and install (make install) soci
to an old Ubuntu (8.04) system without multiarch support.
BTW, maybe we should hand over all the packaging-related stuff,
including choosing proper paths and layout, to SOCI/soci-pkg.
I just think that simple "make install" should not be broken anyways.

Best regards,
Viacheslav Naydenov.

[vnaydionov]

So, @juliantaylor, what do you think -
should we just remove all this "autodetection" stuff to fix .deb and .rpm builds?

if(EXISTS /etc/os-release)
  file(READ /etc/os-release OS_RELEASE)
  string(REGEX MATCH "ID(_LIKE)?=debian" DEBIAN ${OS_RELEASE})
  string(REGEX MATCH "ID(_LIKE)?=fedora" FEDORA ${OS_RELEASE})
  string(REGEX MATCH "ID(_LIKE)?=ubuntu" UBUNTU ${OS_RELEASE})
elseif(EXISTS /etc/lsb-release)
  file(READ /etc/lsb-release OS_RELEASE)
  string(REGEX MATCH "DISTRIB_ID=[Uu]buntu" UBUNTU ${OS_RELEASE})
  string(REGEX MATCH "DISTRIB_ID=[Db]ebian" DEBIAN ${OS_RELEASE})
endif()

if(UBUNTU)
  set(SOCI_LIBDIR "lib")
elseif(DEBIAN)
  execute_process(COMMAND uname -m
                  OUTPUT_VARIABLE SOCI_ARCH
                  OUTPUT_STRIP_TRAILING_WHITESPACE)
  set(SOCI_LIBDIR "lib/${SOCI_ARCH}-linux-gnu")
elseif(APPLE OR CMAKE_SIZEOF_VOID_P EQUAL 4)
  set(SOCI_LIBDIR "lib")
else()
  set(SOCI_LIBDIR "lib64")
endif()

and leave just this:

#Debian always uses lib
set(SOCI_LIBDIR "lib")

[juliantaylor]

yes, I'd remove it all and stick to the build systems default, whatever that is
e.g. opensuse patches its autotools to install into lib64 automatically (which I think is horrible...), maybe the do the same for cmake

that would mean also remove this line and its users:

set(SOCI_LIBDIR "lib")

[vnaydionov]

Ok, I removed autodetection of SOCI_LIBDIR, now Debian package build works fine.