Re: Compilation issue

From: Eric Vidal <>
Date: Wed, 27 Apr 2016 18:09:01 +0400

On Wed, 27 Apr 2016 12:58:24 +0200
Laurent Bercot <> wrote:

> On 27/04/2016 11:21, Eric Vidal wrote:
> > i try to compile skalibs and execline package with
> > --enable-slashpackage options set to s6 for me.
> Hi Eric,
> The argument to --enable-slashpackage, if any, must be an *absolute*
> directory, and one shared by every package you compile "--enable-slashpackage=s6" will not work.
> Generally speaking, if you're interested in following the slashpackage
> convention, you should use --enable-slashpackage but leave the prefix
> empty.

Ok, thank for the explanation.

> If you're installing a package in a staging directory, for a package
> manager or something of the kind, you should *still* leave that prefix
> empty, but use the DESTDIR make variable to install the package into the $DESTDIR staging directory; then when you compile things that depend on
> that package, additionally to --enable-slashpackage, you should use the
> --with-sysdeps, --with-include, --with-lib and --with-dynlib configure
> options to specify where the package can find its dependencies.
> --
> Laurent

I need to precise that i use a FHS filesystem from Arch-linux. So, on it, /bin /sbin /lib are symlinks to /usr/bin (for /bin,/sbin) and /usr/lib(for /lib,/lib64).
Well, when i use the "convention way"(as you said) to compile and make package under this system, i'm confronted to a conflicts files between /usr/bin/imports (from execline package) and /usr/bin/imports from imagemagick.
I need to deplace the origin for your package but i need an advice, i will explain me :
According to this, making a subdirectorie on /usr/bin is not a good idea.
Make a directory directly on root filesystem seem to be not a good idea too for application portability, security reasons etc...(maybe i'm wrong about this)
Maybe a can use /usr/local/?!

So i'm a little confuse about this. Have you an idea?
Eric Vidal <>
Received on Wed Apr 27 2016 - 14:09:01 UTC

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