Creating .deb packages for Lazarus applications?

[dbannon]

I repeat -

Don't forget linux/unix is a multiuser system, once installed, an application should be usable by every user, including ones who did not exist when the application was first installed.

Packages such as debs should not mess around in user space !   Unix systems have all sorts of 'users' installed that are not real users and you risk the wrath of a leather winged dragon from hell if you mess around with their accounts. Its the wrong thing to do.

Its very, very easy to make your app prepare the end user env at first start up -

Does config file exist ?
Yes - read it and use it.
No - create a default config file

Davo

[lucamar]

==> I'm coming back to the lack of a record somewhere in Linux of who was actively logged in, before the root installation [...]

Calling fpGetuid() should give that, as fpGeteuid() should give you the "root" id. The installation runs as root but the real id should still be that of the user who launched it.

But Davo is right: normal user configuration should be deferred until first run and if you have assets that are the same for all users, like images, sounds, etc., they should be copied to the programs folder in /usr/share at install-time, which means your .deb file should reflect this.

[circular]

Unix systems have all sorts of 'users' installed that are not real users and you risk the wrath of a leather winged dragon from hell if you mess around with their accounts.

Isn't it a bit overdramatic?

[PascalDragon]

Unix systems have all sorts of 'users' installed that are not real users and you risk the wrath of a leather winged dragon from hell if you mess around with their accounts.

Isn't it a bit overdramatic?

I'd even go so far as to say that dbannon underestimated that...

[circular]

As a Dragon, I suspect that you opinion is biased.

[devEric69]

Hello,

I'm trying to create a Linux installation, with a system user (adduser --system ...\... a_software_usr). a_software_usr represents the installed software (my_software's proxy, an abstraction of other real users). Then, I've created a single-user software group named a_software_grp containing a_software_usr. I've installed \ dispatched all the binaries released in /opt/my_software/... . Then, I've added the real users - detected during the installation - inside the group named a_software_grp. I'm using setfacl cmd to manage rights on /opt/my_software/... .

I've then said that the /opt/my_software directory belongs, is owned by a_software_usr:a_software_grp. I, i.e. user01, as a real user (not a system user), also belong to a_software_grp. In other words, I use a_software_grp as a proxy group to manage the rights dispatched into /opt/my_software. And real users who want to run a_software, must be added inside this group.

I've got the following problem: in summary, if the permissions given on /opt/a_software are [rwx rwx rwx] i.e. [777], I can launch a_software from a menu launching itself /usr/share/applications/a_software.desktop. But, if I grant /opt/a_software with a less permissive installation, i.e. if the permissions given on /opt/a_software are [rwx rwx ---] i.e. [770], then I get the message "Desktop file invalid: '/usr/share/applications/a_software.desktop'". Same thing: when I run a_software with [770] rights, from a terminal as @user01 or as @root, I get the message "Gtk-WARNING **: 21:02:36.872: cannot open display: ".

Does someone have a clue \ hint, where to look for the reason of this message?

[devEric69]

Okay, it's my fault:

I restarted the commands...

Code: Bash  [Select][+][-]

1. find "${OPT_DIR_OF_A_APPLICATION}" -type d -exec chmod 0755 {} \; #set directory attributes
2. find "${OPT_DIR_OF_A_APPLICATION}". -type f -exec chmod 0644 {} \; #set data file attributes
3. find "${OPT_DIR_OF_A_APPLICATION}/usr/bin" -type f -exec chmod 0755 {} \; #set executable attributes

...in a post-install script embedded in the installation package, to give the same adhoc rights such as described in the paragraph § "Finalizing the staging directory" of the page https://wiki.lazarus.freepascal.org/Debian_package_structure, and the application is launched again well, from a menu. So, the problem of mandating the installation by a system user and a representation group are transparent if I respect the same rights.

Nevertheless, even with the good rights, I always have the problem of launching in a terminal that persists, i.e. I get the message "Gtk-WARNING **: 10:26:05.756: cannot open display:". I can't launch, too, some utilities like xeyes, xclock from a terminal ("Error: Can't open display:"), on a new ghost image of Debian 10 Buster (for information). Of course, it's no longer really a problem of installation, but rather a problem of launching a visual application from a terminal. If anyone have a hint about Xorg \ X11...?

[devEric69]

For information, found on the web: "Graphics applications must be launched by the user who opened the X session. So you should not launch (in a terminal) as root or any other user, but only with the connected one (without su or sudo).".

So...:
- I restarted a terminal as @user01, not as @root, like I used to do.
- I started the cmd: export DISPLAY=:0.0
- I ran the cmd: xclock
...and the small GUI clock, now starts and displays itself. Same thing for the application I'm trying to correctly install (more important, I now see in the terminal the notification messages, OS layer errors, etc).

[circular]

Interesting to know that those rights can have such surprising side effects.