Does your deb have a libpng dependency?
libpng is not declared as a dependency because it is always present in
every distro, and the source API does not care which libpng version is
present. They all work OK.
I am not clear about which dynamically linked libraries should be
declared as dependencies. I have been in the habit of declaring only
those that might not be included in the base OS distribution. I also
declare non-linked utilities, such as xdg-utils.
Why are such dependencies not automatic?
libpng is not declared as a dependency because it is always present in
every distro, and the source API does not care which libpng version is
present. They all work OK.
Still for a working deb you need to declare a dependency on libpng (the version that is in the distro you are targeting, here, trusty).
I am not clear about which dynamically linked libraries should be
declared as dependencies. I have been in the habit of declaring only
those that might not be included in the base OS distribution.
For debian packages, you must declare all direct dependencies, regardless of whether they come in the default installation. During the deb to AppImage conversion, it is then decided which ones to bundle and which ones not to bundle.
Why are such dependencies not automatic?
That is the way deb packages work.
I updated the dependencies in the debian package.
I hope the list is now complete.
I made a working AppImage for the latest Fotoxx that runs on 3
generations of Ubuntu and on Fedora 25. I used a hand-made AppDir and
AppImageTool for this. This package lacks the function for desktop menu
integration. Your package of an earlier Fotoxx release has this. You
also used a tool to convert a debian package into an AppImage. Where is
this tool? In your docs I found only a “deprecated” tool for this.
Q: why did you ask me to provide a debian package for Ubuntu 14.04 when
I wanted to start with 16.04? My current code will not build on 14.04,
so I used an earlier version to make the package you requested.
This is a good packaging concept and I want to go with it. Too bad
desktop Linux is in such chaos that a tool like AppImage is necessary
(and Snap and Flatpack and …).
Mike
Hi @kornelix, the yml file does the debian to AppImage conversion:
https://github.com/probonopd/AppImages/blob/master/recipes/meta/Fotoxx.yml
You can run it with
wget https://raw.githubusercontent.com/probonopd/AppImages/master/recipes/meta/Recipe
bash -ex Recipe Fotoxx.yml
I asked for a 14.04 deb because if you use a 16.04 one, then only very recent distributions (2016 and later) will be able to run the AppImage, all others will get errors. So users of debian stable or CentOS might not be able the AppImage if you use ingredients that have been compiled on a “too new” build system.
It is your decision which target systems (distributions) you want to target, but generally I recommend to target at least the oldest Ubuntu LTS that is still supported. Which means, consequently, that you should only use functionality that can be compiled for the oldest Ubuntu LTS that is still supported.
I hope this clarifies your question.
I think I have enough to continue now.
Thanks for the help.
Mike
Hi @kornelix, fotoxx-17.04-appimage gives
me@host:~$ /home/me/.local/bin/fotoxx-17.04-appimage
--------------------------------------------------
fotoxx-17.04-appimage
(...)
Please install missing programs:
exiftool 8.6 or later
How did it end up in /home/me/.local/bin? I don’t want it there. Also, exiftool should be bundled inside the AppImage.
Also, the latest deb seems to depend on libraw15 which does not seem to exist in Ubuntu trusty. Can you provide a deb for Ubuntu 14.04?
latest fotoxx debian package made with Ubuntu 16.04:
http://www.kornelix.net/downloads/packages-16.04/fotoxx-17.04-x86_64.deb
Sorry I meant Ubuntu 14.04
Your first question:
Exiftool is usually available, so I did not add it to the package. If
missing, Fotoxx politely asks the user to install it. There are several
of these outboard dependencies that are usually present by default.
The appimage package on my web site was not made with your Recipe +
fotoxx.yml.
I did something simpler and easier for me to understand:
- I used a program to list all libraries called by the executable
image, at all call depths - I removed those in your blacklist
- The rest went into AppDir/usr/lib
The rest is standard.
This makes a 30 MB appimage that seems to run fine in the systems
tested: Ubuntu 16.04, 16.10, 17.04, Mint 18.1, Fedora 25.
Wayland and KDE need environment variables to work properly:
GDK_BACKEND=x11, GTK_THEME=default.
Likely the library list can be pruned since they are all available in
all distros, with some exceptions for version revisions. I have not done
this.
Your 2nd question:
If Fotoxx detects that it is an appimage, the executable is relocated to
/home/user/.local/bin and the desktop file to /home/user/.local/share so
that system menu integration is automatic.
I no longer have 14.04 on my computer and do not support it with new
packages.
My base is 16.04 and I provide debian packages built with 16.06, 16.10,
17.04.
GTK APIs and library versions are ever changing, making this messiness
necessary.
Of course you can decide to do what you want, but I politely ask you to include such dependencies, because AppImages are supposed to run “out of the box” on the most common distributions without the user having to install dependencies using the package manager. In fact, this aspect of AppImage is the main reason for its simplicity for the user.
Again, you can decide to do what you want, but I even more ask you to not do this, at least not without asking the user about this. I know that many users like AppImage for the very reason that they can store AppImage files anywhere including on USB drives, on the network and such. And they will be very irritated if the application moves itself. As was I. So please, remove this or at least ask the user.
I think you are making your life harder than necessary. You don’t need to develop against the latest bleeding ever-changing GTK APIs.
Application developers who want to reach users running LTS distributions should always develop for the oldest still-supported LTS version. This way, the software will “automatically” run on newer versions as well. It is like if you develop on Windows 7, then you can expect the application to run on Windows 10 too, but not the other way around.
If exiftool and the other outboard dependencies are included in the
appimage package, presumably all their libraries and other dependencies
would need inclusion. Huge package.
Re: auto-relocation of executable to ~/.local/bin
I agree to change this. I propose not to move it at all, just let the
user move it. When started, the application can update the desktop file
in ~/.local/share/applications if the “Exec=” data is out of sync.
I think you are making your life harder than necessary. You don’t need to develop against the latest bleeding ever-changing GTK APIs.
My code contains many
#if GTK_CHECK_VERSION(…)
to take care of GTK API changes across Ubuntu 16.04, 16.10, and 17.04.
The resulting executables will only load on the Ubuntu releases where
built.
(may also be caused by other library version differences)
Application developers who want to reach users running LTS distributions should always develop for the oldest still-supported LTS version. This way, the software will “automatically” run on newer versions as well. It is like if you develop on Windows 7, then you can expect the application to run on Windows 10 too, but not the other way around.
I was attracted to appimage to avoid some of this chaos and hopefully
extend the range of Linux flavors where an application can run without
custom packaging. Looks good so far. Huge package size is unfortunate,
buy maybe not so important. I was worried about executable startup time,
but this seems fast enough.
If exiftool and the other outboard dependencies are included in the
appimage package, presumably all their libraries and other dependencies
would need inclusion. Huge package.
Yes, that is the price to pay… there is no such thing as a free lunch, as people say. If your app has dependencies, then you should bundle these… as I did with my Fotoxx AppImage. I find the size quite reasonable (still smaller than Photoshop).