SOLVED: The program does not start from a normal user from /usr/bin/ lazarus / 32-Linux ---------------------------------------------------------------------- Renat.Su · 2021-09-11 07:21 Is there a valid Debian packaging structure for ordinary user programs? I made .deb packages for system daemons that needed root access. And I followed the same path for an ordinary GUI application and placed the program in the /usr/bin/ folder (the settings are created in the ~/.config/MY_PROGRAM folder - Pascal GetConfigApp(False) function). So: the program is expected to be launched only using sudo (root access) (access denied for normal Ubuntu user). But I don't need it. How to do it correctly? I have heard that some people place them in the /usr/local/bin/ folder, but according to lintian these are all invalid methods, since they are for self-building applications. Question: where do I store the binary in a deb package? ---------------------------------------------------------------------- MarkMLl · 2021-09-11 07:45 I think this is something I ought to be getting to grips with as well, but my initial comment is that few things in /usr/bin need root, daemons etc. would usually go into /usr/sbin. I've always used /usr/local/bin etc. for locally-generated programs, the other alternative being /opt/bin but it's very rarely used these days (I might have seen SunOS/Solaris putting GNU utilities into that tree). I'd suggest that a good starting point is https://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard, together with the references from its first para. MarkMLl ---------------------------------------------------------------------- devEric69 · 2021-09-11 08:12 Hello, a lot of third party softwares (not compiled locally via source code, a.k.a named "source package", i.e. often not referenceable \ referenced in the official Debian repositories) are installed through their "binary package" *.deb into opt/vendorName. And their configuration files are created in /{(root)|(home/user1)}/.config/vendorName. ---------------------------------------------------------------------- Renat.Su · 2021-09-11 08:43 Quote from: MarkMLl on September 11, 2021, 09:45:22 amI think this is something I ought to be getting to grips with as well, but my initial comment is that few things in /usr/bin need root, daemons etc. would usually go into /usr/sbin.Thanks. Perhaps. I'll think about it. But I'm more concerned now about where to store the binary of my GUI program Quote from: MarkMLl on September 11, 2021, 09:45:22 amI've always used /usr/local/bin etc. for locally-generated programs, the other alternative being /opt/bin but it's very rarely used these days (I might have seen SunOS/Solaris putting GNU utilities into that tree). Quote from: MarkMLl on September 11, 2021, 09:45:22 amYes, I know that some people post there, but it confuses me that this is not recommended I'd suggest that a good starting point is https://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard, together with the references from its first para. It is not recommended while install as a deb package. For example, linitian inform about this. And look at https://wiki.freepascal.org/De bian_package_structure#usr.2Fbin_directory ---------------------------------------------------------------------- Renat.Su · 2021-09-11 08:46 Quote from: devEric69 on September 11, 2021, 10:12:07 amHello, a lot of third party softwares (not compiled locally via source code, a.k.a named "source package", i.e. often not referenceable \ referenced in the official Debian repositories) are installed through their "binary package" *.deb into opt/vendorName. And their configuration files are created in /{(root)|(home/user1)}/.config/vendorName. Thanks. Yes, I'm aware of that. But I am confused by the fact that lintian does not recommend this. I would just like to understand where it is recommended to store the binary in this case. P.S. I keep the settings files there, where you wrote ---------------------------------------------------------------------- Renat.Su · 2021-09-11 09:15 So that my statement does not seem unfounded. Output of the lintian utility: Code: Bash  [Select][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i user@DESKTOP-RENAT:~$ lintian "myapp-full_2.5.3.15-3_amd64.deb" --infoE: myapp: dir-or-file-in-opt opt/myapp/N:N:    Debian packages should not install into /opt, because it is reserved forN:    add-on software.N:N:    Refer to Filesystem Hierarchy Standard (/opt : Add-on applicationN:    software packages) for details.N:N:    Severity: errorN:N:    Check: files/hierarchy-standardN:E: myapp: dir-or-file- in-opt opt/myapp/myapp ---------------------------------------------------------------------- MarkMLl · 2021-09-11 09:49 I'd suggest that that applies to stuff which has been accepted by Debian (or some other distro), i.e. distribution is hosted by them and (potentially) their own signing keys are being used. I'd also suggest that stuff available as a .deb from e.g. Sourceforge would reasonably go into /usr/opt, and stuff that you've built locally into /usr/local. I'd conclude by suggesting that that guidance is /particularly/ relevant if you have both a distro's version of some piece of software, and have a more recent copy from the software's author and/or have built your own copy locally. MarkMLl ---------------------------------------------------------------------- AlexTP · 2021-09-11 12:57 In the Github repo https://github.com/Alexey-T/CudaText you will find the script z_linux_x64_gtk_deb.sh which makes the DEB file. ---------------------------------------------------------------------- Renat.Su · 2021-09-11 13:24 Quote from: Alextp on September 11, 2021, 02:57:14 pmIn the Github repo https://github.com/Alexey-T/CudaText you will find the script z_linux_x64_gtk_deb.sh which makes the DEB file. Thank you, I use your editor by the way. But, if on the topic: there are no problems in creating a deb archive at me. I wanted to find out where I should store binaries if they are not build by the make locally (e.i. proprietary). In your case, the program is open source and it can be installed in /usr/local/bin/. In my particular case, this will not valid. In any case, thank you for the script too ---------------------------------------------------------------------- AlexTP · 2021-09-11 13:27 Sorry then, I mis-read the topic then. ---------------------------------------------------------------------- dbannon · 2021-09-11 13:31 I believe that binaries such as Renat.Su mentions definitely should go into /usr/bin on debian based systems.  Some other flavours use /usr/local/bin. And, yes, as Mark says, things expected to be used by root only should be in */sbin Its not a good idea to put binaries that users are expected to be looking for in the /opt directory, if nothing else, the default user settings don't set a PATH there and the user will not find it.  And its not intended for "general purpose" binaries, more for specific ones that the user, typically a not a real person, will know the full path to. Davo ---------------------------------------------------------------------- Renat.Su · 2021-09-11 14:11 As I came to the conclusion in one of the telegram groups. Add-on application is my GUI application, which does not need root rights and any system capabilities and which is not built by make, i.e. proprietary. Therefore, I can not look at the lintian warning https://forum.lazarus .freepascal.org/index.php/topic,56240.msg417889.html#msg417889 ---------------------------------------------------------------------- Renat.Su · 2021-09-11 14:16 Quote from: dbannon on September 11, 2021, 03:31:28 pmI believe that binaries such as Renat.Su mentions definitely should go into /usr/bin on debian based systems.  Some other flavours use /usr/local/bin. And, yes, as Mark says, things expected to be used by root only should be in */sbin Its not a good idea to put binaries that users are expected to be looking for in the /opt directory, if nothing else, the default user settings don't set a PATH there and the user will not find it.  And its not intended for "general purpose" binaries, more for specific ones that the user, typically a not a real person, will know the full path to. Davo Unlike the daemon that I placed in /usr/bin (or maybe) /usr/sbin, another GUI application, I decided to put it in /opt, because I thought it was intended for this after all: Quotehttps://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch03s13.html /opt is reserved for the installation of add-on application software packages. In this context, “add-on” means software that is not part of the system; for example, any external or third-party software. ---------------------------------------------------------------------- Renat.Su · 2021-09-11 17:59 I apologize to everyone. There was a bug in the program. Previously, it was only portable and I refactored it so that the configs were stored in the appropriate folders, but I missed one place and the program tried to create a file right where it was launched. The bug has been fixed and now the program is freely run from /usr/bin/ from under a regular user without root access. The problem is solved ---------------------------------------------------------------------- devEric69 · 2021-09-12 08:46 Quote from: dbannon on September 11, 2021, 03:31:28 pmIts not a good idea to put binaries that users are expected to be looking for in the /opt directory, if nothing else, the default user settings don't set a PATH there and the user will not find it.  And its not intended for "general purpose" binaries, more for specific ones that the user, typically a not a real person, will know the full path to. Hello @dbannon, I've read a lot about where to install software on Linux distributions. I've come to the conclusion that there is a fuzzy boundary in the installation paths, like a ridge between two mountainsides which are, roughly speaking: ↗ any software that claims to be close to a "Debian server" installation must not go under /opt. And you have to respect lintian's warning, declare variables in PATH, etc ("old school: canonical, framing, strict"). → mix (ridge). ↘ any software that claims to be very specific and\or very commercial (wanting to be in the bootstrap of a large distribution, like Ubuntu- snap for example) must be installed entirely in /opt (there's patchelf to get rid of PATH). The lintian warnings are, here, inappropriate ("new way: inventive, testing, pioneering").