Depends: libgtk2.0-0 (>= 2.0), libgtk2.0-bin (>= 2.0), apt, apt-file
How you find Dependencies?
Is it always the same for Lazarus applications?
How you find Dependencies?
If you wrote the application, you should know.
linux-gate.so.1 => (0x006ad000)
libpthread.so.0 => /lib/libpthread.so.0 (0x4e351000)
libdl.so.2 => /lib/libdl.so.2 (0x4e36d000)
libX11.so.6 => /usr/lib/libX11.so.6 (0x4e6cc000)
libgdk_pixbuf-2.0.so.0 => /usr/lib/libgdk_pixbuf-2.0.so.0 (0x41ad2000)
libgtk-x11-2.0.so.0 => /usr/lib/libgtk-x11-2.0.so.0 (0x42310000)
libgdk-x11-2.0.so.0 => /usr/lib/libgdk-x11-2.0.so.0 (0x428ea000)
libgobject-2.0.so.0 => /lib/libgobject-2.0.so.0 (0x41c4f000)
libglib-2.0.so.0 => /lib/libglib-2.0.so.0 (0x4e403000)
libgthread-2.0.so.0 => /lib/libgthread-2.0.so.0 (0x4e51e000)
libgmodule-2.0.so.0 => /lib/libgmodule-2.0.so.0 (0x4e591000)
libpango-1.0.so.0 => /usr/lib/libpango-1.0.so.0 (0x41d5d000)
libatk-1.0.so.0 => /usr/lib/libatk-1.0.so.0 (0x41da8000)
libcairo.so.2 => /usr/lib/libcairo.so.2 (0x4eaf5000)
libc.so.6 => /lib/libc.so.6 (0x4e1c3000)
/lib/ld-linux.so.2 (0x4e1a2000)
libxcb.so.1 => /usr/lib/libxcb.so.1 (0x4e807000)
libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x4e3c3000)
libgio-2.0.so.0 => /lib/libgio-2.0.so.0 (0x427ba000)
librt.so.1 => /lib/librt.so.1 (0x4e374000)
libpng12.so.0 => /usr/lib/libpng12.so.0 (0x4e864000)
libm.so.6 => /lib/libm.so.6 (0x4e37f000)
libpangocairo-1.0.so.0 => /usr/lib/libpangocairo-1.0.so.0 (0x42110000)
libXfixes.so.3 => /usr/lib/libXfixes.so.3 (0x4eae0000)
libpangoft2-1.0.so.0 => /usr/lib/libpangoft2-1.0.so.0 (0x420e1000)
libfontconfig.so.1 => /usr/lib/libfontconfig.so.1 (0x4e948000)
libXext.so.6 => /usr/lib/libXext.so.6 (0x4e851000)
libXrender.so.1 => /usr/lib/libXrender.so.1 (0x4e93c000)
libXinerama.so.1 => /usr/lib/libXinerama.so.1 (0x4e9dc000)
libXi.so.6 => /usr/lib/libXi.so.6 (0x41c9f000)
libXrandr.so.2 => /usr/lib/libXrandr.so.2 (0x4eaa9000)
libXcursor.so.1 => /usr/lib/libXcursor.so.1 (0x4ead4000)
libXcomposite.so.1 => /usr/lib/libXcomposite.so.1 (0x4e9d7000)
libXdamage.so.1 => /usr/lib/libXdamage.so.1 (0x4e9d2000)
libpixman-1.so.0 => /usr/lib/libpixman-1.so.0 (0x4ea2c000)
libfreetype.so.6 => /usr/lib/libfreetype.so.6 (0x4e88f000)
libz.so.1 => /lib/libz.so.1 (0x4e3ab000)
libXau.so.6 => /usr/lib/libXau.so.6 (0x4e6c7000)
libresolv.so.2 => /lib/libresolv.so.2 (0x4e525000)
libselinux.so.1 => /lib/libselinux.so.1 (0x4e3e2000)
libexpat.so.1 => /lib/libexpat.so.1 (0x4e827000)
libc6, libgdk-pixbuf2.0-0, libglib2.0-0, libgtk2.0-0, libatk1.0-0, libcairo2, libfreetype6, libpango1.0-0, libssl0.9.8
You can add more or less, most packages are likely to be already present on the system, because they are common.Thanks flames for the clear and helpful post, but adding "less" because packages are probably already present on a system seems a bit... optimistic to me.
dpkg --print-architectureamd64mkdir debian
touch debian/controldpkg-shlibdeps -O project1shlibs:Depends=libatk1.0-0 (>= 1.12.4), libc6 (>= 2.2.5), libcairo2 (>= 1.2.4), libgdk-pixbuf2.0-0 (>= 2.22.0), libglib2.0-0 (>= 2.12.0), libgtk2.0-0 (>= 2.24.0), libpango-1.0-0 (>= 1.18.0), libx11-6Architecture: amd64
Depends: libatk1.0-0 (>= 1.12.4), libc6 (>= 2.2.5), libcairo2 (>= 1.2.4), libgdk-pixbuf2.0-0 (>= 2.22.0), libglib2.0-0 (>= 2.12.0), libgtk2.0-0 (>= 2.24.0), libpango-1.0-0 (>= 1.18.0), libx11-6
SIZE_IN_KB="$(du -s ${STAGING_DIR} | awk '{print $1;}')"
echo "Installed-Size: ${SIZE_IN_KB}" >> "${STAGING_DIR}/DEBIAN/control"
If I understand correctly you add the files:Possibly, but the lclstrconsts.mo does not change with your application, its the same file for every application you make on one version of Lazarus, it may change in small ways between versions. I have not yet come across an end user with more than one Lazarus app installed - thats sad !
/usr/share/locale/*/LC_MESSAGES/lclstrconsts.mo
Wouldn't that may cause an interference with another program doing the same? When removing the other program, wouldn't that remove this file as well?
The Installed-Size seems to be fixed to 4096. Instead, you could compute it when all files are ready to be archived:Indeed you are right. I put 4096 in because, when I started, my app was less than this, it has grown since then so its certainly wrong now !Code: [Select]SIZE_IN_KB="$(du -s ${STAGING_DIR} | awk '{print $1;}')"
echo "Installed-Size: ${SIZE_IN_KB}" >> "${STAGING_DIR}/DEBIAN/control"
.....
The method provided by @circular for finding the dependencies is new to me (it looks like everyone just keep suggesting the use of either ldd or elf, which are not that helpful). I'll try it!
shlibs:Depends=libatk1.0-0 (>= 1.12.4), libc6 (>= 2.2.5), libcairo2 (>= 1.2.4), libgdk-pixbuf2.0-0 (>= 2.22.0), libglib2.0-0 (>= 2.12.0), libgtk2.0-0 (>= 2.24.0), libpango-1.0-0 (>= 1.18.0), libx11-6 Here is a guide on how to make an upstream source for Debian:Really useful pair of pages Circular, I inteneded to do something similar for some time but, well, you know ! I have added a small section to Debian Package Structure to define the difference between Source and Binary packages. Hope you don't mind.
https://wiki.freepascal.org/Debian_upstream
In principle, it is possible just to supply the source with the Makefile and request that someone would make the packaging for Debian distributions.
I use debuild, with that I can make a src package acceptable to Ubuntu in a PPA, https://launchpad.net/~d-bannon/+archive/ubuntu/ppa-tomboy-ngIn fact, the main difference is that pbuilder does not assume that you have the packages installed on your system. So it can be useful to check that you have all the dependencies defined in control file. Apart from that, it seems debuild is fine and it is faster when building things over and over again.
I am working on the legal aspects of Debian, if we can get over that, I hope to use the same model to make Debian SRC packages although I have seen hints they they might prefer pbuilder.
At present my model is that I have a script (prepare.bash) that takes a zip file downloaded from GitHub containg all my source and it builds the directory structure of a debian src package. Inside that scr package the make file does much of the usual build and install things but to actually compile the Pascal source, it calls another script (buildit.bash) that uses both lazbuild (to build a dependency) and fpc to build the actual app.Yeah. Well as far as I understand it, whether it is a script or not, you need to provide a repository with all files necessary to build. Apparently they prefer it to be on https://salsa.debian.org. You can include the debian folder, so that (p)debuild can be run on top of it. You can use fpc and lazbuild as long as you add the build dependencies (fpc, lcl, lazarus and libqt5pas-dev).
Not a simple process !
The Debian process is quite well documented in very many pages on the Debian website, I suggest that not be duplicated on our wiki. But how that official process needs to be fiddled to work with FPC/Lazarus would be useful indeed. Its a steep learning curve.Well there is a lot of documentation, but it is not obvious to find what you are looking for. Also it is indeed not adapted to FreePascal. But yeah, it is better to make links to Debian documentation when possible.
But you must keep in mind that, for example, when it recommends we needCode: [Select]shlibs:Depends=libatk1.0-0 (>= 1.12.4), libc6 (>= 2.2.5), libcairo2 (>= 1.2.4), libgdk-pixbuf2.0-0 (>= 2.22.0), libglib2.0-0 (>= 2.12.0), libgtk2.0-0 (>= 2.24.0), libpango-1.0-0 (>= 1.18.0), libx11-6all the packages listed (except libgtk2.0-0) are, themselves dependencies of libgtk2.0-0.
How do you come to your conclusions?
* Apt command ? apt-rdepends from memory.
* You need a clean distro that has not got gtk2 already, then install gtk2 and see what extra packages are listed as about to be installed.Thanks for the advice: I'll look in a virtual machine.
* Apt command ? apt-rdepends from memory.
apt show libgtk2.0-0 will do it;"apt show" displays the dependencies very well, exactly what I want. I can "redemonstrate" the conclusions of dbannon with my script now:
Not sure why you would need to know all the dependencies. If you specify that you need gtk2, then all the rest will be installed. Or did I miss something?No, you didn't miss anything: I just wanted to automate - in a IT way - the series of commands (ldd, ...) described on the page https://wiki.freepascal.org/Deploying_Your_Application (https://wiki.freepascal.org/Deploying_Your_Application), to cross-check the results with the "official" Debian command dpkg-shlibdeps -O %s explained in https://wiki.freepascal.org/Debian_package_structure (https://wiki.freepascal.org/Debian_package_structure), and retrieve only the really necessary, needed packages.
Help!
I encounter a problem, with the user's /home directory (the /home directory of the user who is installing the package), creating a Debian package, with the following scenario:
- a user named user_1 wants to install an application packaged in an the_appli.deb file.
- he starts the installation (of the_appli.deb file).
.....
Here is a more general documentation I just wrote:
https://wiki.freepascal.org/Debian_package_structure
One way to deal with it though is to install this file as a resource (in /usr/share/the_appli) and when your application starts, to check if the file exists in the .config directory. If not to copy it from the resource directory.
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.
At this stage, the install should be running as root and if it has dependencies, apt installs them first. Apt install never makes changes at the user level, if, for example, the user will need some config files or directories created, that should happen when, later, they run the application for the first time.
this scripts copy the config for all users.Indeed. So, not a real one *single-user* application's installation :-\ .
==> I'm coming back to the lack of a record somewhere in Linux of who was actively logged in, before the root installation [...]
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?
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?
Does anybody have any experience in making Debian packages for Lazarus programs?
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).".
While there is no reason why you cannot backup an old installation, its not really in keeping with the Debian Packaging model.
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 ?
Also found two programs to make Debian packages. I haven't tested them - Link #2Has anyone had any experience with the Debian Packager (http://www.getlazarus.org/apps/makedeb/), in the meantime ?
Making a binary is easy ...Should be as shown here (https://www.youtube.com/watch?v=az4IvDUDGig&t=4s) for FFmpeg.