cryos / avogadro

Avogadro 1 is not under active development, the repository was archived in September 2021. Development of Avogadro 2 is being done at https://github.com/openchemistry/avogadrolibs. Avogadro is an advanced molecular editor designed for cross-platform use in computational chemistry, molecular modeling, bioinformatics, materials science, and related areas.
http://avogadro.cc/
GNU General Public License v2.0
336 stars 156 forks source link

Feature request: Cross-distribution package for Linux #874

Open fusion809 opened 7 years ago

fusion809 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

@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 commented 7 years ago

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

fusion809 commented 7 years ago

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 commented 7 years ago

Updated the bug with what I get.

sagitter commented 7 years ago

@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.

/usr/include/eigen3/Eigen/Core:321:2: error: #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 commented 7 years ago

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

fusion809 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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

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

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

fusion809 commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

Please see https://github.com/cryos/avogadro/pull/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 commented 6 years ago

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... :100:

HenriqueCSJ commented 6 years ago

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 notifications@github.com 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 https://github.com/cryos/avogadro/issues/874#issuecomment-394077659, or mute the thread https://github.com/notifications/unsubscribe-auth/AAjDwoj7AC3krdR_nVCStz-u8MM8y29Qks5t4mypgaJpZM4N-py9 .

-- Henrique C. S. Junior

fusion809 commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

@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 commented 6 years ago

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

fusion809 commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

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 commented 5 years ago

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.