View Issue Details

IDProjectCategoryView StatusLast Update
0005633GNUnetbuild processpublic2019-05-02 14:36
Reporterng0Assigned To 
PrioritynormalSeveritytextReproducibilityhave not tried
Status confirmedResolutionopen 
Product VersionSVN HEAD 
Target Version0.12.0Fixed in Version 
Summary0005633: investigate and fix wrong install location of libexec
Descriptionon macOS, Debian, pkgsrc-wip, and possibly other OS and package manager systems "libexec" ends up in
"lib/gnunet/libexec". This is an anomaly considering that our Makefiles look alright, our configure script
is possibly okay, and considering the fact that other EPREFIX candidates end up in $DESTDIR (for example bin
and lib). Because it ought to be EPREFIX/libexec/gnunet as per our Makefiles, something is wrong here.

The good part is, it is consistent in being wrong across all systems, so whatever is wrong works as intended.
For pkgsrc correctness, I prefer to have libexec really in $EPREFIX together with lib, bin, and other EPREFIX
folders. Guix and Nix where possible prefer this top level of libexec as well.

I've tried a couple of combinations and configure time options and variations in my pkgsrc package, nothing
can convince our buildsystem that libexec shouldn't be in lib/, and I don't want to patch in pkgsrc when I can
fix stuff where it should be fixed.
TagsNo tags attached.

Activities

Christian Grothoff

2019-03-07 14:45

manager   ~0014162

Eh, but the correct location is lib/gnunet/libexec/, that's where we need the service binaries. You will also find similar things for other packages:

/usr/lib/llvm-3.8/libexec/c++-analyzer
/usr/lib/llvm-3.8/libexec/ccc-analyzer
/usr/lib/x86_64-linux-gnu/libexec/kf5/kdesu
/usr/lib/x86_64-linux-gnu/libexec/kf5/kdesu_stub
/usr/lib/x86_64-linux-gnu/libexec/kf5/kdesud
/usr/lib/x86_64-linux-gnu/qt5/libexec/QtWebDatabaseProcess
/usr/lib/x86_64-linux-gnu/qt5/libexec/QtWebNetworkProcess
/usr/lib/x86_64-linux-gnu/qt5/libexec/QtWebProcess


AFAIK, this is the canonical location for binaries that are executable but should NOT be in the $PATH.

ng0

2019-03-07 19:10

developer   ~0014163

My ${LIBEXEC_DIR} begs to differ with "canonical" (as does nix and guix), the point being that we don't allow to switch the
location even when we set it.

Unless this is intended behavior by the autotools, in which case I would resolve this and file it under knowledge learned through packaging with expectations".
Note that pkgsrc does not mandate a "/libexec" in the destdir, but follows rather what upstream does.. upstream being
us. So it's not a mistake, I'm just trying to figure out why the configure switches are apparently being ignored by the build system

ng0

2019-03-07 19:16

developer   ~0014164

Thing being why I ask: it's not so common in the pkgsrc tree to have lib/$name/libexec/, at least in my installed packages.
A search into the pkgsrc tree gives me: libmicro, gcc49, kde4, some special cases (cross compilers), fcitx, but not many more.
packages with lib/libexec/ containing binaries stand out, libexec/name/* is the default location.

schanzen

2019-03-08 08:55

developer   ~0014165

http://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch04s07.html

ng0

2019-03-08 11:34

developer   ~0014166

I know what the specs say.
Please read what the mentioned system do about it before just posting a link to something I already know, besides this is not the point.
The configure arguments are discussed here. If we don't hardcode the location of $thing/gnunet/libexec or rather $libexec, the modification of its location should work.
But it doesn't.
So it doesn't matter what the specs say when there's an individual or by chosen preference or norm of the packaging system to ignore parts of the spec.
If I can't conform to the specs I either need to acknowledge that and see if I can fix it here or if I can't fix it here for whatever reasons, I need to write a note about the ignorance of our buildsystem towards the responsible switches.
How we individually think or care about FHS is not relevant.

schanzen

2019-03-08 12:07

developer   ~0014167

I think your interpretation of the spec is wron.
The libexec dir and putting non-user-executable binaries under <prefix>/lib/ (in our case gnunet/libexec) are two different things.
Changing the libexec dir is possible by default through autotools I assume. However, it does not have any effect because we do not install anything in the libexec dir.
In fact, we are not even allowed to do it because the spec says if we use <prefix>/lib for our binaries, we must not install anything into the libexec dir.
Just because it is convention to install binaries into <prefix>/lib/<name>/libexec (see gcc, llvm) it does not mean that this location suddenly becomes the libexec dir.

ng0

2019-03-08 12:45

developer   ~0014168

Okay, I'll take another look at everything and reply. Can take a while.

schanzen

2019-03-08 16:06

developer   ~0014171

Check src/include/gnunet_os_lib.h:165.
A quick grep also shows me that we also do not use LIBEXEC anywhere.
What we do use is GNUNET_OS_IPK_LIBEXECDIR, which is "lib/gnunet/libexec/" according to a comment in the file above

I think this issue's tl;dr is:
1. We do not install anything in LIBEXEC_DIR
2. A change in LIBEXEC_DIR through configure or the environment does not matter because we are not using it
3. We install everything under lib/gnunet/* so this issue might be invalid/wontfix unless we change the build system and install the binaries into LIBEXEC_DIR/gnunet which would also require changes in the source (see above)

ng0

2019-03-08 17:29

developer   ~0014172

Okay, was busy elsewhere until a couple of minutes ago.
2 should be documented and 3 is in the scope of what I wanted to clarify here.it's definitely a feature bug,
but more involved.

Christian Grothoff

2019-03-09 01:35

manager   ~0014173

Note that it won't be easy/possible to use LIBEXEC_DIR. The user can set LIBEXEC_DIR independently of lib/, and if they do that, we won't be able to find our executeables anymore. We determine the path for lib/gnunet/libexec/ *from* the path of lib/libgnunetutil.so (as that is our own code, we are sure we can ask Linux for its location). So given lib/libgnunetutil.so, we can determine lib/gnunet/libexec/. But if the user has set a LIBEXEC_DIR to foo/, we won't know where foo/ is! Sure, we could then hard-code foo/ into the libgnunetutil.so binary, but then the installation would no longer be relocatable. So the current method is a feature, not a bug.

ng0

2019-03-09 11:58

developer   ~0014174

Alright, I think then it's enough to document this with the reasons provided in this ticket
and pointing to this ticket.

ng0

2019-03-09 11:59

developer   ~0014175

Keeping this open until someone has added the appropriate documentation changes (README, configure.ac maybe, doc/handbook, doc/tutorial maybe).

Issue History

Date Modified Username Field Change
2019-03-07 01:05 ng0 New Issue
2019-03-07 14:45 Christian Grothoff Note Added: 0014162
2019-03-07 19:10 ng0 Note Added: 0014163
2019-03-07 19:16 ng0 Note Added: 0014164
2019-03-08 08:55 schanzen Note Added: 0014165
2019-03-08 11:34 ng0 Note Added: 0014166
2019-03-08 12:07 schanzen Note Added: 0014167
2019-03-08 12:45 ng0 Note Added: 0014168
2019-03-08 12:45 ng0 Assigned To => ng0
2019-03-08 12:45 ng0 Status new => assigned
2019-03-08 16:06 schanzen Note Added: 0014171
2019-03-08 17:29 ng0 Note Added: 0014172
2019-03-09 01:35 Christian Grothoff Note Added: 0014173
2019-03-09 11:58 ng0 Note Added: 0014174
2019-03-09 11:59 ng0 Note Added: 0014175
2019-03-09 11:59 ng0 Assigned To ng0 =>
2019-05-02 14:36 Christian Grothoff Severity minor => text
2019-05-02 14:36 Christian Grothoff Status assigned => confirmed
2019-05-02 14:36 Christian Grothoff Product Version => SVN HEAD