View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0005633 | GNUnet | build process | public | 2019-03-07 00:05 | 2024-02-11 10:44 |
| Reporter | nikita | Assigned To | schanzen | Due Date | |
| Priority | normal | Severity | text | Reproducibility | have not tried |
| Status | closed | Resolution | fixed | ||
| Product Version | Git master | ||||
| Target Version | 0.14.1 | Fixed in Version | 0.14.1 | ||
| Summary | 0005633: Document why we install libexecs where they ends up | ||||
| Description | on 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. | ||||
| Tags | No tags attached. | ||||
| 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. | |
| 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 | |
| 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. | |
| http://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch04s07.html | |
| 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. | |
| 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. | |
| Okay, I'll take another look at everything and reply. Can take a while. | |
| 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) | |
| 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. | |
| 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. | |
| Alright, I think then it's enough to document this with the reasons provided in this ticket and pointing to this ticket. | |
| Keeping this open until someone has added the appropriate documentation changes (README, configure.ac maybe, doc/handbook, doc/tutorial maybe). | |
| Documented in c54fdac50..b47586e76 | |
| 0.14.1 released | |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2019-03-07 00:05 | nikita | New Issue | |
| 2019-03-07 13:45 | Christian Grothoff | Note Added: 0014162 | |
| 2019-03-07 18:10 | nikita | Note Added: 0014163 | |
| 2019-03-07 18:16 | nikita | Note Added: 0014164 | |
| 2019-03-08 07:55 | schanzen | Note Added: 0014165 | |
| 2019-03-08 10:34 | nikita | Note Added: 0014166 | |
| 2019-03-08 11:07 | schanzen | Note Added: 0014167 | |
| 2019-03-08 11:45 | nikita | Note Added: 0014168 | |
| 2019-03-08 11:45 | nikita | Assigned To | => nikita |
| 2019-03-08 11:45 | nikita | Status | new => assigned |
| 2019-03-08 15:06 | schanzen | Note Added: 0014171 | |
| 2019-03-08 16:29 | nikita | Note Added: 0014172 | |
| 2019-03-09 00:35 | Christian Grothoff | Note Added: 0014173 | |
| 2019-03-09 10:58 | nikita | Note Added: 0014174 | |
| 2019-03-09 10:59 | nikita | Note Added: 0014175 | |
| 2019-03-09 10:59 | nikita | Assigned To | nikita => |
| 2019-05-02 12:36 | Christian Grothoff | Severity | minor => text |
| 2019-05-02 12:36 | Christian Grothoff | Status | assigned => confirmed |
| 2019-05-02 12:36 | Christian Grothoff | Product Version | => Git master |
| 2019-07-01 11:44 | nikita | Assigned To | => nikita |
| 2019-07-01 11:44 | nikita | Status | confirmed => assigned |
| 2019-07-28 13:56 | nikita | Assigned To | nikita => |
| 2019-11-16 17:40 | Christian Grothoff | Target Version | 0.12.0 => |
| 2019-12-10 15:23 | nikita | Assigned To | => nikita |
| 2020-04-25 14:12 | nikita | Summary | investigate and fix wrong install location of libexec => Document why we install libexecs where they ends up |
| 2020-05-31 22:49 | Issue cloned: 0006306 | ||
| 2021-02-28 12:34 | schanzen | Assigned To | nikita => schanzen |
| 2021-02-28 12:53 | schanzen | Tag Attached: documentation | |
| 2021-03-14 13:05 | schanzen | Status | assigned => resolved |
| 2021-03-14 13:05 | schanzen | Resolution | open => fixed |
| 2021-03-14 13:05 | schanzen | Fixed in Version | => 0.14.1 |
| 2021-03-14 13:05 | schanzen | Note Added: 0017621 | |
| 2021-03-23 15:14 | schanzen | Target Version | => 0.14.1 |
| 2021-04-05 09:25 | schanzen | Note Added: 0017684 | |
| 2021-04-05 09:25 | schanzen | Status | resolved => closed |
| 2024-02-11 10:44 | Christian Grothoff | Tag Detached: documentation |