View Issue Details

IDProjectCategoryView StatusLast Update
0005633GNUnetbuild processpublic2024-02-11 11:44
Reporternikita Assigned Toschanzen  
PrioritynormalSeveritytextReproducibilityhave not tried
Status closedResolutionfixed 
Product VersionGit master 
Target Version0.14.1Fixed in Version0.14.1 
Summary0005633: Document why we install libexecs where they ends up
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.


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:


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


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


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.


2019-03-08 08:55

administrator   ~0014165


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.


2019-03-08 12:07

administrator   ~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.


2019-03-08 12:45

developer   ~0014168

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


2019-03-08 16:06

administrator   ~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)


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'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/ (as that is our own code, we are sure we can ask Linux for its location). So given lib/, 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 binary, but then the installation would no longer be relocatable. So the current method is a feature, not a bug.


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.


2019-03-09 11:59

developer   ~0014175

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


2021-03-14 14:05

administrator   ~0017621

Documented in c54fdac50..b47586e76


2021-04-05 11:25

administrator   ~0017684

0.14.1 released

Issue History

Date Modified Username Field Change
2019-03-07 01:05 nikita New Issue
2019-03-07 14:45 Christian Grothoff Note Added: 0014162
2019-03-07 19:10 nikita Note Added: 0014163
2019-03-07 19:16 nikita Note Added: 0014164
2019-03-08 08:55 schanzen Note Added: 0014165
2019-03-08 11:34 nikita Note Added: 0014166
2019-03-08 12:07 schanzen Note Added: 0014167
2019-03-08 12:45 nikita Note Added: 0014168
2019-03-08 12:45 nikita Assigned To => nikita
2019-03-08 12:45 nikita Status new => assigned
2019-03-08 16:06 schanzen Note Added: 0014171
2019-03-08 17:29 nikita Note Added: 0014172
2019-03-09 01:35 Christian Grothoff Note Added: 0014173
2019-03-09 11:58 nikita Note Added: 0014174
2019-03-09 11:59 nikita Note Added: 0014175
2019-03-09 11:59 nikita Assigned To nikita =>
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 => Git master
2019-07-01 13:44 nikita Assigned To => nikita
2019-07-01 13:44 nikita Status confirmed => assigned
2019-07-28 15:56 nikita Assigned To nikita =>
2019-11-16 18:40 Christian Grothoff Target Version 0.12.0 =>
2019-12-10 16:23 nikita Assigned To => nikita
2020-04-25 16:12 nikita Summary investigate and fix wrong install location of libexec => Document why we install libexecs where they ends up
2020-06-01 00:49 Adminknox Issue cloned: 0006306
2021-02-28 13:34 schanzen Assigned To nikita => schanzen
2021-02-28 13:53 schanzen Tag Attached: documentation
2021-03-14 14:05 schanzen Status assigned => resolved
2021-03-14 14:05 schanzen Resolution open => fixed
2021-03-14 14:05 schanzen Fixed in Version => 0.14.1
2021-03-14 14:05 schanzen Note Added: 0017621
2021-03-23 16:14 schanzen Target Version => 0.14.1
2021-04-05 11:25 schanzen Note Added: 0017684
2021-04-05 11:25 schanzen Status resolved => closed
2024-02-11 11:44 Christian Grothoff Tag Detached: documentation