Feature request: Cross-distribution package for Linux

[fusion809]

Hi,

I think Linux users of this project, myself included, would really appreciate it if a cross-distribution package for Avogadro was provided. I'm using Gentoo Linux and while its official repos have packages for both Avogadro and Avogadro2 I'm presently getting configure failures so if a cross-distribution package was available I'd be able to use this wonderful application. If I could suggest a great cross-distribution package format for Linux it'd be AppImage, although I'm not picky and I don't think many other Linux users would be either so long as it is cross-distribution and runs on most popular distributions I'd be grateful.

Thanks for your time,
Brenton

[cryos]

This is a great suggestion, and something I would like to do. I have looked at a few approaches, but haven't found the time to implement something. No promises on timeline but I think we need to do better at providing friendly binaries outside of the package managers, and supporting package managers if they are willing to package too.

[HenriqueCSJ]

I do believe that the best practice is to focus on Flatpak[1].
It will work in any distribution, it is under heavy development.
[1] - http://flatpak.org/

[sagitter]

I'm using Gentoo Linux and while its official repos have packages for both Avogadro and Avogadro2 I'm presently getting configure failures so if a cross-distribution package was available I'd be able to use this wonderful application.

This is what is happening on Gentoo, of course, not on every Linux distribution. So, why not resolve your configuration issues?

[fusion809]

@sagitter Ya great idea but the bug that stopped me has already been reported at the Gentoo Bugzilla (https://bugs.gentoo.org/show_bug.cgi?id=619544) and so far no fix has been provided. If you know the fix please do comment it on the bug at Gentoo Bugzilla.

[sagitter]

@fusion809
Which "Eigen errors"?
https://bugs.gentoo.org/show_bug.cgi?id=619544#c3

[fusion809]

As it failed for this guy I didn't bother trying the patch. But if you give me a moment I'll try it and upload the log to the bug.

[fusion809]

Updated the bug with what I get.

[sagitter]

@fusion809
From latest build log (https://bugs.gentoo.org/show_bug.cgi?id=619544#c4) looks you are using a no-supported version of Eigen.

�[01m�[K/usr/include/eigen3/Eigen/Core:321:2:�[m�[K �[01;31m�[Kerror: �[m�[K#error Eigen2-support is only available up to version 3.2. Please go to "http://eigen.tuxfamily.org/index.php?title=Eigen2" for further information

[fusion809]

So downgrade to ≤3.2? Shall try and see if it works.

[fusion809]

Thanks your solution worked! Shall report this fix at Gentoo Bugzilla. Must admit though I still think an AppImage/Flatpak/Snap would have some value. I could see CentOS users possibly wanting it as their repos don't include Avogadro.

[sagitter]

I could see CentOS users possibly wanting it as their repos don't include Avogadro.

Maybe, i can build Avogadro2 on EPEL7 repos for CentOS 7.
http://copr-fe.cloud.fedoraproject.org/coprs/sagitter/ForTesting/builds/

[cryos]

I would gladly help where I could in getting things packaged, I think choosing a cross-distro binary package as an alternative would be ideal. Avogadro 2 now requires C++11 which I know can make things a little tougher on some distributions.

[probonopd]

Let me know if there is interest in having an AppImage.

Providing an AppImage would have, among others, these advantages:

• Applications packaged as an AppImage can run on many distributions (including Ubuntu, Fedora, openSUSE, CentOS, elementaryOS, Linux Mint, and others)
• One app = one file = super simple for users: just download one AppImage file, make it executable, and run
• No unpacking or installation necessary
• No root needed
• No system libraries changed
• Works out of the box, no installation of runtimes needed
• Optional desktop integration with appimaged
• Optional binary delta updates, e.g., for continuous builds (only download the binary diff) using AppImageUpdate
• Can optionally GPG2-sign your AppImages (inside the file)
• Works on Live ISOs
• Can use the same AppImages when dual-booting multiple distributions

Here is an overview of projects that are already distributing upstream-provided, official AppImages.

[fusion809]

Does anyone know a distro that has a bug-free Avogadro 1.2.0 package, either in their official or unofficial repositories, that is old (at least three years old), yet supported? I ask because I've noticed on openSUSE Tumbleweed Avogadro 1.2.0 doesn't launch due to bugs too and it seems on quite a few distros Avogadro is either outdated or buggy, so I'd like to create an AppImage for it.

[probonopd]

Development of Avogadro 2 is being done at https://github.com/openchemistry/avogadrolibs - isn't that the newer one that we should be focusing on?

[fusion809]

Working with it wouldn't hurt, but Avogadro2 is in pre-release development not production ready, still missing a few important features that Avogadro 1 even has. So until then Avogadro 1 would be ideal to be packaged.

[probonopd]

Please see #907. Test builds of the Avogadro AppImage are available for download at https://github.com/probonopd/avogadro/releases. Let me know if there are any remaining issues.

[probonopd]

By the way, I have documented the whole procedure on how this pull request was made at https://www.youtube.com/watch?v=UJJKnr-WO0Y - so in case you have other favorite applications that don't have an AppImage yet, this is how you can make similar pull requests... 💯

[HenriqueCSJ]

It is probably better to create a Flatpak instead. Flatpak is a cross-distribution package manager that aims to become a standard (and is backed by the great distros). https://www.flatpak.org/

…

On Sat, Jun 2, 2018 at 7:44 AM probonopd ***@***.***> wrote: By the way, I have documented the whole procedure on how this pull request was made at https://www.youtube.com/watch?v=UJJKnr-WO0Y - so in case you have other favorite applications that don't have an AppImage yet, this is how you can make similar pull requests... 💯 — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#874 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAjDwoj7AC3krdR_nVCStz-u8MM8y29Qks5t4mypgaJpZM4N-py9> .

-- *Henrique C. S. Junior*

[fusion809]

I sense a tinkling contest coming here, AppImage vs Flatpak vs ... (Snap perhaps). We could turn it into a race to see which package format gets to the finishing line first. @HenriqueCSJ You can build a Flatpak, while @probonopd & I'll work on the AppImage. I'd say ready-set-go, but @probonopd & I have already started...

[fusion809]

Well technically I didn't start this issue specifying that AppImage alone was what this issue was about. Like the title of this ticket itself doesn't mention it specifically. My original comment was also fairly open, but yes this issue has largely focused on AppImages as I did mention AppImage in the opening comment.

[HenriqueCSJ]

Unfortunately, I don't have the time to deal with packaging anymore. Sorry. But it looked like a good advice to point out that the major distros are all looking at Snap and Flatpak at this point (with Flatpak having several advantages because it does not rely on Ubuntu specific libs).
I know that Linux, in general, is still far from getting THE ONE Universal package, but this is where the winds are blowing right now.

[probonopd]

But it looked like a good advice to point out that the major distros are all looking at Snap and Flatpak at this point (with Flatpak having several advantages because it does not rely on Ubuntu specific libs)

AppImage is specifically designed to need no special support from the distribution, and hence AppImages can run just about anywhere - such as RHEL, CentOS, openSUSE, SLED, Ubuntu, Fedora, debian and derivatives.

Looking at the numbers, it seems like there are some indications that AppImage actually might have the largest following of the three systems mentioned, although one never can actually be sure.

[fusion809]

@probonopd I concur. AppImages seem to be on the rise. If we were to look for which cross-distro package format has the largest number of programs packaged as it, we'd probably find, however, Nix wins hands down (I recall reading it's >6,000 packages). It is packaged, for the most part, by NixOS devs, not upstream projects and many of those packages are, of course, core system components and alike, not application software. Even when we restrict ourselves to application software I think it'd still win as it is designed to provide all the application software needed by an entire distribution.

EDIT: It even has an Avogadro package, but it doesn't work (per NixOS/nixpkgs#34307) any more.

[probonopd]

err, right, I was referring to tools for upstream application authors to publish their software themselves.

[fusion809]

Ya, sorry I'm not sure why went off on that tangent. Nevertheless AppImages have the beauty that users don't have to wait for their distro's packagers to package some package manager like Flatpak or Snap, so they have a clear advantage. Most users use the major distros but there's dozens of independent distros with small packaging teams where if a Flatpak package exists there's no guarantee it won't get broken from time and time and it might take a while to get fixed. Plus Flatpak and Snap do assume someone with root privileges installs the package manager itself at some point. AppImages make no such assumption.

[cryos]

Thanks for looking at this, I would like to improve packaging for Linux. I think Avogadro 2 is closer than you might think, but we would rather support both 1 and 2 for the short term. My attention is more focused on 2, and getting it to a stage where people don't tell me it is a long way from production ready. I am not sure which is the best packaging format, but would prefer to choose one and generate that.

[fusion809]

I think the question should be:

1. "Which format can I, an end-user, obtain and use as fast as possible?"

   The answer then would be simple: AppImages. Generally speaking AppImages are smaller than Flatpaks and Snaps, after accounting for dependencies, meaning faster downloads and they take no preparation, besides chmod +x'ing, to be used (i.e. you don't need to install the package manager, then get the package manager to download and install the app and its deps), once you've downloaded them you can use them.

2. "Which format can be used on all modern distributions, without their packagers having to lift a finger?" AppImages! The only set in stone dependencies of AppImages are FUSE and a modern Linux system (with 'modern' being something that devs get to define in the way they build the AppImages).

3. "Which format has the least potential to be mucked up by anyone but the app's packagers?" AppImages! This is relevant as you's would be the packagers, so that means every bug would be more in your control, not third-parties!

   As AppImages have so few dependencies and the chief developer of the format has shown he (@probonopd) is committed to his AppImages project (relevant in case a bug related to the AppImage format itself arises)—as he's been developing AppImages for significantly longer than Snaps and Flatpaks have been around—it seems unlikely that something could get broken that would be out of your hands.

   Flatpaks and Snaps, as they depend on their own respective package manager can be easily mucked up by four groups of people, other than the app's packagers: (1) the respective developers and (2) packagers of the package managers themselves, and (3) the respective developers and (4) packagers of the package manager's respective dependencies. Granted it's on the package manager's developers to protect against (3)-related issues, so one may be able to ignore that.

@probonopd If you've got something to add, or something I got wrong (accidentally, of course), please do say.

[probonopd]

Well said @fusion809 but since we don't want to deviate too much from the topic here, let me just point to https://github.com/AppImage/AppImageKit/wiki/Similar-projects where we did a comparison of the projects (from our point of view but independently fact-checked).

[cryos]

I really appreciate the input, there are a number of open source projects I am involved in where I would like to improve what we currently do. I will see if I can get to the bottom of packaging, I think I am sold. I use Arch most of the time, with some Ubuntu mixed in, but am also interested in providing easy to use packages for all common Linux distributions (I was once a Gentoo developer/package maintainer).

[FRidh]

Note Nixpkgs has a function to create a Snap out of a Nix package. Therefore, building a Snap out of the Avogadro package in Nixpkgs should not be a problem. Note I don't use Avogadro nor now its current state in our repo.