Recent

Author Topic: Creating .deb packages for Lazarus applications?  (Read 34427 times)

dbannon

  • Hero Member
  • *****
  • Posts: 2786
    • tomboy-ng, a rewrite of the classic Tomboy
Re: Creating .deb packages for Lazarus applications?
« Reply #45 on: November 22, 2020, 08:23:49 am »
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
Lazarus 3, Linux (and reluctantly Win10/11, OSX Monterey)
My Project - https://github.com/tomboy-notes/tomboy-ng and my github - https://github.com/davidbannon

lucamar

  • Hero Member
  • *****
  • Posts: 4219
Re: Creating .deb packages for Lazarus applications?
« Reply #46 on: November 22, 2020, 01:10:01 pm »
==> 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.
« Last Edit: November 22, 2020, 01:14:12 pm by lucamar »
Turbo Pascal 3 CP/M - Amstrad PCW 8256 (512 KB !!!) :P
Lazarus/FPC 2.0.8/3.0.4 & 2.0.12/3.2.0 - 32/64 bits on:
(K|L|X)Ubuntu 12..18, Windows XP, 7, 10 and various DOSes.

circular

  • Hero Member
  • *****
  • Posts: 4195
    • Personal webpage
Re: Creating .deb packages for Lazarus applications?
« Reply #47 on: November 22, 2020, 01:19:57 pm »
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?
Conscience is the debugger of the mind

PascalDragon

  • Hero Member
  • *****
  • Posts: 5446
  • Compiler Developer
Re: Creating .deb packages for Lazarus applications?
« Reply #48 on: November 22, 2020, 01:22:19 pm »
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

  • Hero Member
  • *****
  • Posts: 4195
    • Personal webpage
Re: Creating .deb packages for Lazarus applications?
« Reply #49 on: November 22, 2020, 01:24:58 pm »
As a Dragon, I suspect that you opinion is biased.
Conscience is the debugger of the mind

devEric69

  • Hero Member
  • *****
  • Posts: 648
Re: Creating .deb packages for Lazarus applications?
« Reply #50 on: February 03, 2021, 09:36:49 pm »
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?
« Last Edit: February 03, 2021, 10:31:56 pm by devEric69 »
use: Linux 64 bits (Ubuntu 20.04 LTS).
Lazarus version: 2.0.4 (svn revision: 62502M) compiled with fpc 3.0.4 - fpDebug \ Dwarf3.

devEric69

  • Hero Member
  • *****
  • Posts: 648
Re: Creating .deb packages for Lazarus applications?
« Reply #51 on: February 04, 2021, 10:53:35 am »
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...?
« Last Edit: February 04, 2021, 04:16:56 pm by devEric69 »
use: Linux 64 bits (Ubuntu 20.04 LTS).
Lazarus version: 2.0.4 (svn revision: 62502M) compiled with fpc 3.0.4 - fpDebug \ Dwarf3.

devEric69

  • Hero Member
  • *****
  • Posts: 648
Re: Creating .deb packages for Lazarus applications?
« Reply #52 on: February 04, 2021, 12:26:21 pm »
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).
« Last Edit: February 04, 2021, 04:17:07 pm by devEric69 »
use: Linux 64 bits (Ubuntu 20.04 LTS).
Lazarus version: 2.0.4 (svn revision: 62502M) compiled with fpc 3.0.4 - fpDebug \ Dwarf3.

circular

  • Hero Member
  • *****
  • Posts: 4195
    • Personal webpage
Re: Creating .deb packages for Lazarus applications?
« Reply #53 on: February 05, 2021, 02:59:16 am »
Interesting to know that those rights can have such surprising side effects.
Conscience is the debugger of the mind

vladimirr

  • New Member
  • *
  • Posts: 29
Re: Creating .deb packages for Lazarus applications?
« Reply #54 on: March 25, 2021, 05:39:33 pm »
Does anybody have any experience in making Debian packages for Lazarus programs?

I use Debreate - Debian Package Builder.

https://antumdeluge.github.io/debreate-web/

MarkMLl

  • Hero Member
  • *****
  • Posts: 6676
Re: Creating .deb packages for Lazarus applications?
« Reply #55 on: March 25, 2021, 07:46:33 pm »
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).".

Somebody on the Internet is wrong https://xkcd.com/386/ You can generally run a command as root provided that you use sudo's -E option... which is unavoidable if you think about it since a complete ban on root logging in via ssh and on ordinary (but authenticated and authorised) users switching to root would result in a total inability to run graphics-based management tools remotely.

There might, of course, be other factors involved such as the ownership of FIFOs in /tmp or in the original user's ~ And there's ways round it like using POSIX capabilities. And the wisdom of running anything as complex as a GUI-based program with elevated permissions is moot. And so on.

MarkMLl
MT+86 & Turbo Pascal v1 on CCP/M-86, multitasking with LAN & graphics in 128Kb.
Pet hate: people who boast about the size and sophistication of their computer.
GitHub repositories: https://github.com/MarkMLl?tab=repositories

devEric69

  • Hero Member
  • *****
  • Posts: 648
Re: Creating .deb packages for Lazarus applications?
« Reply #56 on: September 02, 2021, 04:14:04 pm »
Hello,

I've created a Debian version 0 installation of a software, say named "softfoo". Everything is installed in the /opt/softfoo/* directory (a kind of miniature fractalized directory of a Linux). For a new installation, from scratch, the Debian installation softfoo_0.0.0.0_amd64.deb installs all very correctly. I'm happy.

Now, I'm creating a Debian version 1 installation. And of course, I'm now testing the "switch case" of maintainer scripts (prerm, preinst, postrm, postinst; Cf. https://wiki.debian.org/MaintainerScripts) in oder to upgrade from version 1 over an already installed version 0. To be complete, in this case, my upgrade only needs to replace the old *.elf binary, and some *.htm online help files in situ, instead of the old ones [^]. For the rest, the new *.elf will update the old centralised database, the old *.conf files, ..., by itself.

Question number 1: I've a constraint which is that I want to preserve an old detected installation (number 0, here). So, I want to do a bash cmd "mv" from the old installation towards /opt/softfoo_old_historized_version_0/*. I was thinking of writing this in the script '1->preinst "switch case" upgrade) 0', and rollback\cancel on error in 'this->postrm "switch case" abort-upgrade) 0'. Is this correct?

Question number 2: for file replacements (Cf. [^*] above , i.e. in order to replace an existing old *.elf, and existing old *.htm online help files), my question is: where, in which maintainer script and with which event script "switch case" (upgrade, configure, ...), is it advisable to script (verify\validate\invalidate) such file to file replacement of a previous installation, and especially how to tell not to replace an old existing database (my installation and my database are in fact centralized: I install a software that can be launched by all users alternatively, but all using the same database)? I would like to code this as much as possible into a upgrade event script "switch case" (for semantic purpose).

Regards.
« Last Edit: September 02, 2021, 04:43:01 pm by devEric69 »
use: Linux 64 bits (Ubuntu 20.04 LTS).
Lazarus version: 2.0.4 (svn revision: 62502M) compiled with fpc 3.0.4 - fpDebug \ Dwarf3.

devEric69

  • Hero Member
  • *****
  • Posts: 648
Re: Creating .deb packages for Lazarus applications?
« Reply #57 on: September 02, 2021, 05:58:17 pm »
So, after having read, re-read the Debian events flowchart and its documentation several times, here is what I think is notable in my upgrade context:



       ...\...
'$old->prerm upgrade) $new'     nb: I should code the reverse if it fails in '$new->prerm failed-upgrade) $old'
          ↓
'$new->preinst upgrade) $old'     nb: I should code the reverse if it fails in '$new->postrm abort-upgrade) $old'
          ↓
The new package files are unpacked and they are written, overwriting the old ones that are still there (so, it seems that I should have to rename the database in one of the 2 scripts before, in order not to lose it, to backup it), as far as I understand.
          ↓
'$old->postrm upgrade) $new'     nb: I should code the reverse if it fails in '$new->postrm failed-upgrade) $old'
                                                           and 'postrm' means 'overwritten' here


So, in this event, I should be able to rename an existing backuped database in place of the newly comming one. Then, the Debian Installer says that it will remove all the files that were in the listing of the old installation, but are not present in this new installation.
       ...\...




Is this what we should infer?
« Last Edit: September 02, 2021, 06:02:24 pm by devEric69 »
use: Linux 64 bits (Ubuntu 20.04 LTS).
Lazarus version: 2.0.4 (svn revision: 62502M) compiled with fpc 3.0.4 - fpDebug \ Dwarf3.

dbannon

  • Hero Member
  • *****
  • Posts: 2786
    • tomboy-ng, a rewrite of the classic Tomboy
Re: Creating .deb packages for Lazarus applications?
« Reply #58 on: September 03, 2021, 02:23:09 am »
While there is no reason why you cannot backup an old installation, its not really in keeping with the Debian Packaging model. That says you should upgrade anything that needs it and remove things no longer needed.

With Debian packages, its a continuous process, you can keep applying the new version over the old one and not  take up much more diskspace each time.  If you make a backup copy, and do another Debian update, and it makes a backup copy, and the next one makes yet another backup copy .....

Mind you, if you are providing just binary packages direct to users and not making source packages to submit to Debian, you are free to do what you wish !

Could you, instead, offer a "roll back" package, one that replaces your newer one with the old version and have a utility that converts the newer data back to the old format ?

Davo
Lazarus 3, Linux (and reluctantly Win10/11, OSX Monterey)
My Project - https://github.com/tomboy-notes/tomboy-ng and my github - https://github.com/davidbannon

devEric69

  • Hero Member
  • *****
  • Posts: 648
Re: Creating .deb packages for Lazarus applications?
« Reply #59 on: September 03, 2021, 12:17:38 pm »
Hello @Davo,

While there is no reason why you cannot backup an old installation, its not really in keeping with the Debian Packaging model.

Just for information, this backup of a previous installation was inspired by looking at the bash 'maintainer scripts' of a Debian installation of the Firebird servers.  I thought it was clever: indeed, if a big bug in a new version (which never happens, of course ::) <-- eyes applied to myself ) appears, then the old one can easily be put back on work again.

For information, I'll only provide binary packages (not yet at the top level in order to allow source packages (*.pas) to be fetched from a repository with dependencies like Lazbuild in order to do a rebuild of everything on the user's machine (like a true "Debian-proof" source package).

Could you, instead, offer a "roll back" package, one that replaces your newer one with the old version and have a utility that converts the newer data back to the old format ?

Well, I thought about that (using solutions such as LazAutoUpdater). But, at the end, I've decided that it should be the new *.elf (installed in place of the old one) that will carry the responsibility of updating everything around it that needs to be updated.
« Last Edit: September 03, 2021, 02:25:20 pm by devEric69 »
use: Linux 64 bits (Ubuntu 20.04 LTS).
Lazarus version: 2.0.4 (svn revision: 62502M) compiled with fpc 3.0.4 - fpDebug \ Dwarf3.

 

TinyPortal © 2005-2018