Atom: Add Linux software repositories for app update support

[29e7e280-0d1c-4bba-98fe-f7cd3ca7500a]

launchpad.net
would you please release atom for ubuntu , as a launchpad ppa repository?

[AnotherJoSmith]

It has already been done unofficially: https://launchpad.net/~webupd8team/+archive/ubuntu/atom

[thedaniel]

This is definitely something we'll consider.

[29e7e280-0d1c-4bba-98fe-f7cd3ca7500a]

This repo lacks of maintained, Out of date.
So if there be an official PPA, it's good to us.

[wldcordeiro]

@netroby The PPA @AnotherJoSmith linked to is up to date with the official Atom releases, so I'm not sure what you're referring to. I imagine that once the editor is further along in development they will add an official PPA though.

[fbrundu]

@wldcordeiro Unfortunately it has not been updated in the last two weeks..

[jehrhardt]

A PPA is an Ubuntu specific solution and great for packages, that have dependencies on other version specific packages.

Google uses a more flexible solution for Chrome. Chrome for Linux can be downloaded as a DEB package from the same page as the Mac and Windows versions. The user can double click the package to install it through a graphical interface. The package has no additional dependencies and can be installed on different Ubuntu, Debian, etc. versions. During installation the package registers a Google server as additional repository, so Chrome is updated through the system.

This way is more flexible, not restricted to Ubuntu and easy to use for less terminal aware people. I would recommend to copy this way from Google instead of creating an official PPA.

[hendricha]

I highly support Google's way and am kind of suprised practically no
other app for linux project does this. (And I'm not a Google fanboy, I
don't even use Chrome/Chromium for browsing.)

[wldcordeiro]

@jehrhardt I like that approach. I think targeting Debian based distros first would be best since they have the largest market share and then adding in support for Fedora or others.

[jehrhardt]

@wldcordeiro +1

Is there anything concrete, that I could do to make this happen soon?

[thedaniel]

I went ahead and created an account on Launchpad for atomeditor so we have a place to do this.

[thedaniel]

Having a proper Chrome-like updater on Linux would be awesome, but at the very least having a PPA and .deb downloads on the site is a good first step. We already have a grunt task that uploads an amd64 deb to https://github.com/atom/atom/releases, so providing a download is done/almost done. I'll open an issue specifically about a grunt task for publishing to a PPA as well.

[robertknight]

@hendricha Dropbox uses the same approach as Google Chrome and Mendeley does as well. It defeats the point of apt's security but it offers a good user experience compared to setting up a PPA.

For those who aren't familiar with them, these apps are downloaded as a .deb package. During the package's install scripts they add a new apt source file in /etc/apt/sources.list.d/ and register the public key for the repo.

[jehrhardt]

@robertknight 👍

[alanfranz]

Hello everybody,
since I needed this where I work as well as at home, I created a deb repository. This tracks the official github releases deb, it's not a rebuild. Feel free to share with anybody.

http://debrepos.franzoni.eu/

[wldcordeiro]

@alanfranz That's great, but @AnotherJoSmith pointed out another repo that's around. Maybe you should collaborate?

[alanfranz]

@wldcordeiro no, that's not the same. That's a rebuild, and such rebuild is got some documented issues e.g. https://github.com/atom/atom/issues/3713 - I was using such repo myself before.

My repo is just a friendly way of installing OFFICIAL builds from https://github.com/atom/atom/releases/

[jelmerdemaat]

Is there any update on this?

Currently I use the .deb files to install on Ubuntu 14.10 which works great. :+1:

But I would like a more automatic process (e.g. not having to browse to /releases to find the latest .deb and manually do a sudo dpkg -i).
Or is there a non-changing link to the latest deb file? I tried some urls like https://github.com/atom/atom/releases/download/latest/atom-amd64.deb but that doesn't work.
If there would be such a link I could easily write a simple update/install shell script.

Thanks!

[thedaniel]

@jelmerdemaat https://atom.io/download/deb is what you want.

[alanfranz]

@jelmerdemaat I know it's "unofficial" but since I needed it I put up a repository on http://debrepos.franzoni.eu . It's updated for new releases about every hour.

[jelmerdemaat]

@thedaniel Thanks! Didn't notice this link on the website as I primarily use GitHub. @alanfranz Thanks for the suggestion, but indeed I'm careful with adding unofficial PPA's to Ubuntu. I'll wait for an official one and untill then use a small custom update script.

[alanfranz]

@jelmerdemaat of course. I have added on debrepos.franzoni.eu the small script that I use to download the updated releases. It uses the feedparser python library and aptly. Feel free to download and modify it to create a local repository for your own consumption.

[pierriko]

Here is a small update script I'm using until the official ppa is running: https://gist.github.com/pierriko/8f64d64b9d3212d62754

[sarod]

+1
ppa:webupd8team/atom works fine though it would be nice to have something official

[Joshua-Anderson]

I'd love for a PPA as well. If you guys need any help implementing this feel free to contact me.

[donlencho]

+1
Although of course it would be even better to be in the official repo for future releases of the distributions so it would be directly available in any software installer. Don't see why the distro managers wouldn't approve that.

[190n]

+1

[thedaniel]

IIRC this is blocked until Atom can be built without network access.

[50Wliu]

How does the Webupd8 PPA do it? Perhaps their method could be used for this?

[Joshua-Anderson]

They zip up builds of atom and extract it into the deb. It isn't a great solution. Ideally we would have a command the downloads but does not build all dependencies.

[Dannyzen]

+1

[Joshua-Anderson]

As a alternative to launchpad, packagecloud also offers free apt repository posting and allows you to directly upload Debian packages. It's a single command to upload and would be easy to do as part of a release process. I'd be happy to help set it up if there is interest, but it would need to mostly be done by whoever uploads the official Debian packages to the atom website.

[amingilani]

+1000

Please, please, please.

[wreckah]

:+1:

[sudopluto]

For the rpm side of things, the openSUSE build service could be used to provide repositories for rpm based distros.

[devurandom]

openSUSE can also build Ubuntu packages, afaik. (See e.g. the ownCloud Client repository it builds.) And then there is Travis and Jenkins.

[Yajo]

@devurandom Posting the link FWIW: http://software.opensuse.org/download/package?project=isv:ownCloud:community&package=owncloud

[sudopluto]

Since nobody else wants to take the initiative, I guess I will. I wanted to avoid doing this because I am new to Linux, but maybe it will be a good learning experience. I have never compiled source code before, so if you want to help, pls let me know.

[alanfranz]

@sudopluto the point is that many people want an "official" repository from atom developers, not a 3rd party repository.

If you want a 3rd party repository hosting exactly the release .deb which are released by atom developers, there's already my repo at www.a9f.eu

[sudopluto]

@thedaniel

IIRC this is blocked until Atom can be built without network access.

Copr (the Fedora version of ppa) has a build service that has internet access. There is already unofficial copr repo here:
It would be really nice to have an official repo for updating atom since the updates are so frequent. All you need to use Copr is a source rpm package, which should be created when the rpm is built.

[alex94cp]

@sudopluto +1 for not only a PPA (Ubuntu-only)

[hendricha]

What if it is not a PPA repository, just a generic (but _official_) deb
repository, like what eg. Google has?

2015-06-15 16:11 keltezéssel, Alejandro Caravaca Puchades írta:

@sudopluto https://github.com/sudopluto +1 for not only a PPA
(Ubuntu-only)

—
Reply to this email directly or view it on GitHub
https://github.com/atom/atom/issues/2956#issuecomment-112082822.

[190n]

@hendricha +1 - I use Debian and Debian doesn't support PPAs, but it still has deb packages.

[isiahmeadows]

FWIW, Google Chrome, in its install .deb, literally adds its own repo to /etc/sources.d, and updates apt/yum/etc. accordingly. They use the built-in plumbing to update, using their repo instead of the distro's one. They don't even touch the main PPAs.

This wouldn't be a bad idea for updating, since the need for using anything distro-specific is no longer necessary. AFAIK, Google does similar with .rpm's as well, but it's only an educated guess.

[isiahmeadows]

@190n PPAs are specific to Ubuntu and its "official" derivatives, such as Kubuntu and Ubuntu GNOME.

[isiahmeadows]

And for the whole thing, definitely +1.

[n054]

Worked long and hard yesterday to get to the end of the file for beautimous atom build. I see there's a block on it right at the spot I was forced to end my work as someone/thing interfered by taking me off line. I will keep checking the repository for updates but for now I have sooo many more builds I need to finish.

[isiahmeadows]

For what it's worth, this is partly why I installed GDebi. So I wouldn't
have to break out a command line each time I install from a DEB.

On Tue, Jun 23, 2015, 22:19 Nora Lorinda Nattress [email protected]
wrote:

Worked long and hard yesterday to get to the end of the file for
beautimous atom build. I see there's a block on it right at the spot I was
forced to end my work as someone/thing interfered by taking me off line. I
will keep checking the repository for updates but for now I have sooo many
more builds I need to finish.

—
Reply to this email directly or view it on GitHub
https://github.com/atom/atom/issues/2956#issuecomment-114702199.

[AsaAyers]

Since this is obviously never going to get fixed, here's a script to run every once in a while to upgrade.

#!/bin/bash

cd /tmp
wget https://atom.io/download/deb -O atom.deb
sudo dpkg -i atom.deb

[isiahmeadows]

It will. Not much thought has gone into it so far, though, but if you
search the issue tracker, you should find a more detailed bug than this.
And the current issue needing resolved is the means of transmission. PPAs
are Ubuntu-specific, DEBs are not.

On Tue, Jun 23, 2015, 23:27 Asa Ayers [email protected] wrote:

Since this is obviously never going to get fixed, here's a script to run
every once in a while to upgrade.

!/bin/bash

cd /tmp
wget https://atom.io/download/deb -O atom.deb
sudo dpkg -i atom.deb

—
Reply to this email directly or view it on GitHub
https://github.com/atom/atom/issues/2956#issuecomment-114717070.

[dhollinger]

@impinball What about YUM repo for RPM-based distros? In that case SUSE is the odd man out that DOESN'T use YUM for RPM package management.

Either way, a PPA and YUM repo would be really nice. Especially since Ubuntu (and derivatives) and Fedora are among the most heavily used Distros for Development (besides Arch).

Automatic updating is REALLY needed on the Linux side of things.

[isiahmeadows]

I use Ubuntu exclusively, so that's what I'm most familiar with. I don't
know all the details about how Google Chrome's installers work, especially
for RPM distros, since I'm not a Googler. I know it uses APT because I
upgrade it through apt-get. And I know Debian uses apt-get as well, so it's
unlikely Google doesn't use it. I honestly know little about how either is
packaged, since I deal very little with the back end of package managers.

On Tue, Jun 23, 2015, 23:42 David Hollinger III [email protected]
wrote:

@impinball https://github.com/impinball What about YUM repo for
RPM-based distros. In that case SUSE is the odd man out that DOESN'T use
YUM for RPM package management.

Either way, a PPA and YUM repo would be really nice. Especially since
Ubuntu (and derivatives) and Fedora are among the most heavily used Distros
for Development (besides Arch)

—
Reply to this email directly or view it on GitHub
https://github.com/atom/atom/issues/2956#issuecomment-114718843.

[sudopluto]

As I stated before if the packager for atom decided to use OBS then it can build packages and repos for Ubuntu, Fedora, openSuSE and more. At this point it seems more likely that visual studio code will get repo support sooner than atom, so I have switched to that as my code editor.

[mehcode]

In case anyone wants something to help ease the the problem now (while we wait for the atom team to get time to work on an official auto-updating solution) -- I made the following (mostly for myself so no guarantee that it works): https://www.npmjs.com/package/atom-updater

Just npm i -g atom-updater, run atom-updater, and enjoy.

[mehcode]

Small update to the above; the package I made now does auto-update (in the background).

https://github.com/mehcode/atom-updater#auto-pilot-for-systemd

[stanier]

This is receiving a disappointing amount of neglect. We should have had this implemented before 1.0.

Is this going to be resolved or should we assume that the ball will continue to be dropped for Linux?

[maxbrunsfeld]

I made the following (mostly for myself so no guarantee that it works): https://www.npmjs.com/package/atom-updater

This is really cool @mehcode.

To everyone who is interested in this feature: we're sorry we haven't gotten around to it. As always, we'd love help setting it up. All of our build scripts are in the repo.

[stanier]

I'll go ahead and take a swing at it, though I may be slower since I'm not all too familiar with CoffeeScript.

@maxbrunsfeld, is there any significance to the package auto-updater? I've come across it twice now but can't find any reference to it by package.json or any other parts of the project.

Also @mehcode, me like. Mind if I possibly steal some of atom-updater's code to get this working?

[mnquintana]

FWIW, I think it would be good to choose a direction on this before anyone gets too deep in the code. :sweat_smile:

In the past we've talked about forgoing automatic updates in Atom proper in favor of native package managers on Linux. Is that still the direction we want to go with here? (@atom/feedback)

[mehcode]

Also @mehcode, me like. Mind if I possibly steal some of atom-updater's code to get this working?

Steal away. It's served me well. Been through 3 automatic version upgrades with no problems (so far).

[stanier]

Well @mnquintana until some direction is expressed, I'm going to continue to work on an upgrade mechanism that is independent of package managers, as it seems that pushing to a mainstream repo would take a lot longer to discuss than it should.

[thomasjo]

We will almost surely not use the official repos (unless necessary for individual distributions). Instead we should use the approach taken by Google for Chrome/Chromium and NVIDIA for e.g. the CUDA toolkit, and that is to release a .deb (and similar) which adds an Atom maintained repository for Atom releases. That way we can leverage the distributions' update mechanism for free, yet be able to quickly publish new releases.

I'm not convinced doing it any other way is worth it given the disparity amongst the most frequently used distributions. It's much more difficult to get something Squirrel to work across all Linux distributions compared to Windows and OS X. Although I'm not a core team member, just a highly opinionated collaborator, so take this comment with a pinch of salt :speak_no_evil:

[robertknight]

That way we can leverage the distributions' update mechanism for free, yet be able to quickly publish new releases.

+1 - This makes a mockery of apt security but it gives a good user experience for Ubuntu (and other distributions to varying degrees). What we did for Mendeley that was very similar to Chrome was:

• Generate a .deb package, configured to install /etc/apt/sources.list.d/appname.list when installed and also register the key for the repository via a post-install script at the same time. This ensures that future updates must at least come from the same source as the original provider.
• Use apt-ftparchive to generate a repository containing the .deb package. We use the newer 'pool' format which stores all the packages in one directory and the various metadata files under a separate directory.
• Upload generated repository to S3 and serve it from there

The principle downside of using the system update mechanism is that the update installation experience is not as good as a custom one could be - it requires the user to type their password and is (relatively) slow if you haven't recently installed any other packages because of the way that apt reads the entire package cache of thousands of files before installing a package.

[stanier]

The current solution for updating that I'm working on implementing is as follows:

• Detect distro
• Get update information from https://atom.io/api/updates
• Compare update.version from API's response, grab either https://atom.io/download/deb or https://atom.io/download/rpm depending on distro
• Schedule install with quitAndInstall function, remove file afterwards

From what I understand, this is a rough equivalent of the Windows update mechanism, as per SquirrelUpdate and auto-updater-win32.

The advantages of this solution are:

• Compatibility with auto-update-manager with virtually no modification of it
• No additional hosting needed
• Security is uncompromised; installs update as if manually downloaded, no circumventing repository lists security
• Since update info is grabbed with curl -L each time, there is no need to update the mechanism if the repository location changes-- it will follow location headers

Another solution would be to have apm start handling the updates, though I can imagine this would require a lot of a work to get working.

[sgoblin]

You could also see how nodesource and docker do it:
https://docs.docker.com/installation/ubuntulinux/#installation
https://github.com/nodesource/distributions

[Joshua-Anderson]

I created a unofficial debian repository.

It is connected to travis-ci and a heroku cronjob to check hourly for atom updates and publishes them.

You can read more at joshua-anderson/atom-uploader if you're interested.

[anaisbetts]

Dear @kevinsawicki @thedaniel,

I'll just leave this here:
https://gist.github.com/paulcbetts/4981ccdaa45398d3405b

I bet if you replaced all of the words 'slack' with 'atom', then signed up for packagecloud.io, and put these scripts in /etc/cron.daily in both mkrpm and mkdeb, a cool thing might happen!

Love and Free Software,
@paulcbetts

[thomasjo]

Dear @kevinsawicki @thedaniel,

I'll just leave this here:
https://gist.github.com/paulcbetts/4981ccdaa45398d3405b

I bet if you replaced all of the words 'slack' with 'atom', then signed up for packagecloud.io, and put these scripts in /etc/cron.daily in both mkrpm and mkdeb, a cool thing might happen!

Love and Free Software,
@paulcbetts

:heart::heart::heart:

[amayer5125]

@alanfranz is there something wrong with your repo? I just did a dnf upgrade --refresh and it says there are no updates. I checked the actuall files and _atom-1.0.13.x86_64.rpm_ is there but the repodata file seems to be outdated.

[alanfranz]

@amayer5125 thanks for your report. It seems that an invalid RPM package had been published in the Atom releases feed, and that caused my createrepo invocation to break. It's fixed now. Next time please report at https://github.com/alanfranz/atom-text-editor-repository , I happened to read your comment almost by chance!

[maxbrunsfeld]

It seems that an invalid RPM package had been published in the Atom releases feed

@alanfranz I wasn't aware of this. What was the problem with the package?

[alanfranz]

@maxbrunsfeld I've double checked the issue (it was quite late last night); it seems that it was rather a glitch with my own upload system caused by unexpected data in the releases feed. There has been in the xml feed of the releases a release labeled v1.0.13 (Rather than just 1.0.13, probably a wrong release name since it's now gone or renamed) and there still is a 1.1.0-beta without RPM or DEB artifacts; when downloading them the library I used did not check for errors as I expected, so a rogue html file with GitHub's own 404 page became an RPM file.

Now the thing is getting corrected.

[amayer5125]

@alanfranz thanks :)

[p-e-w]

This issue is becoming very frustrating to watch. Well past the 1.0 release Linux support in Atom still lags far behind OS X and Windows. No automatic updates, no official repositories, no code signing ... This is strange given that Linux is actually _more popular than Windows_ with Atom users according to this poll. In fact, Ubuntu alone accounts for more responses than Windows 8, and equals OS X Yosemite.

To add insult to injury, a PR implementing an update mechanism for Linux is still being ignored by the Atom team after two and a half months(!). :disappointed:

I would love to help bringing proper Linux update support to Atom, but I'm unsure how. Looking at the fate of the aforementioned pull request, "implement it yourself" is clearly _not_ the answer. An official deb/rpm repository would be ideal IMO, and, as the third-party repos posted above show, almost trivial to implement in its simplest form (auto-publish of stable versions). This, however, is the one part where community work alone just doesn't cut it – official maintenance by GitHub and package signing with their keys is a must for many people to add a new repository to their Linux system's package manager (Chrome repo being maintained by Google works for the same reason).

[sgoblin]

GitHub has also set up a repository for git-lfs on packagecloud.io: https://packagecloud.io/github/git-lfs/install
Perhaps they could do the same for atom?
Edited to fix URL, thanks 50Wliu!

[50Wliu]

@sgoblin I think you linked the wrong URL :P.

[ryanpcmcquen]

For anyone out there building Atom on a non-deb/rpm distro, I have a script I use that builds Atom from source and always grabs the latest version by parsing the release page:

https://github.com/ryanpcmcquen/ryanpc-slackbuilds/tree/master/unofficial/atom

Although it is geared toward Slackware, it could easily be modified to work on any distro (probably by changing the makepkg line).

[amingilani]

This issue is not closed, the pull request at #9425 was rejected. Please reopen this issue immediately. Also, please tell me who I should contact in order to help setup an offical PPA.

[mnquintana]

@amingilani This issue is not closed - it's still open. This remains something that we want to add, but the core team hasn't had time for this yet. This will happen eventually though.

[luispabon]

This should be on a repository, and not a separate package download.

[luispabon]

It was argued before what Google do. What Google do with Chrome and other packages on Debian/Ubuntu is to provide with an initial .deb download that, once installed, it also sets up the required repositories so that these are covered by the OS's normal software management tools.

[dhollinger]

@luispabon Google also does that for Chrome on RPM-based distributions using YUM or DNF as well

[luispabon]

:+1: I'd been amazed if they hadn't.

[cazacugmihai]

+1

[Yajo]

Although I agree with this issue, you should take time to open bugs in your preferred distros to ask them to package Atom, the same way they package other IDEs.

[nemonein]

+1

[edwinksl]

:+1:

[piit79]

@Yajo Although it might be nice to eventually have Atom in official distribution repositories this is not very convenient for projects with fast development. It takes quite a long time to publish new versions so the distribution would always be several versions behind.
Can't wait to have an official atom repo, don't quite understand what's taking so long... But I'll be patient and use one of the unofficial ways to update :)

[bmlyon]

+1

[abraxxa]

+1

[tomecki]

+1

[ghost]

+1

ppa:webupd8team/atom works but an official package would be better.

[pjmp]

A big +1 from me too

[tsimonq2]

Don't we just need a Debian Developer to make this happen? Then it will just sync down to Ubuntu and Linux Mint and such.

FWIW +1

[Joshua-Anderson]

@tsimonq2 Ideally atom would host their own repository. I love the Debian software repository and hope that atom gets into there, but it also takes ~ 6 months to 1 year for updates to trickle down from upstream release to Ubuntu, making it non-ideal for applications like atom with a fast development cycle.

[tsimonq2]

@Joshua-Anderson At first I was going to respond with an "I don't think so," but after reviewing both release cycles and talking to a few DDs, you might be right, so what's the progress?

[thuandt]

Atom still not support automatic update via repos in Ubuntu. So sad :(

[1dot75cm]

I also created a unofficial Fedora repository. It has the following features:

• split package atom, nodejs-atom-package-manager and electron
• reduced rpm package size

I want to add atom to the Fedora official repository. Now it has the following problems:

• need to build electron from source code
• continue split atom

For Fedora/RHEL7 end user, please execution follows command:

$ sudo dnf copr enable mosuqito/atom
$ sudo dnf install atom

Please visit https://copr.fedorainfracloud.org/coprs/mosquito/atom

[simonkberg]

Since atom-updater stopped working with atom 1.7.0, and the maintainer seems to have abandoned the project, I decided to create a new cli tool in node for keeping atom up to date: atom-check-updates (acu).

install using npm i -g atom-check-updates and run as acu. Can also be used for updating beta releases acu -b. Prompts for confirmation before install by default, but can be overridden with acu -y.

Should work on any debian och rpm-based distro. Open an issue if it doesn't!

[ames89]

Thank you @simonkberg, works perfectly!

[alanfranz]

@ames89 @simonkberg please remember there's always https://github.com/alanfranz/atom-text-editor-repository . I don't plan to drop it soon :-)

[ericoporto]

The webupd8 ppa is still the best one for Ubuntu if someone is curious.

[Yajo]

@1dot75cm Could you update please? I use your package and am having some bugs that I think are fixed on last release.

[piesha]

https://discuss.atom.io/t/why-isnt-atom-in-any-official-repository/29294/4

Too bad...

<3

[1dot75cm]

I has been updated atom to 1.7.4. Currently, it is working properly. @Yajo

• atom 1.7.4-2.git6bed3e5
• nodejs-atom-package-manager 1.10.0-5.git87b4bcb
• electron 1.2.0-1.prebuilt

[edwinksl]

For Ubuntu users who are interested in installing snaps, I came across a /r/Ubuntu Reddit post at https://www.reddit.com/r/Ubuntu/comments/4mjjsu/what_snap_packaged_software_would_you_like_to_see/d3w655r where the OP made a snap for Atom.

[Yajo]

@1dot75cm Thanks!

@atom How about a Flatpak?
https://blogs.gnome.org/mclasen/2016/06/07/modularity-and-the-desktop/
http://flatpak.org/

[sudopluto]

I think the only distro that is pushing flatpak right now is fedora. I don't think they have it up and running.

[Yajo]

It will come by default in core GNOME in next releases, not only in Fedora AFAIK.

[sudopluto]

Honestly I'm going to switch over to vscode because they are adding deb / rpm repos soon. I think it's funny that Microsoft is better at supporting linux users compared to GitHub. https://github.com/Microsoft/vscode/issues/2973

[ericoporto]

Not only this, but the Github interface is exclusively for Windows and Mac OSX, which sucks.

[edwinksl]

@ericoporto GitHub interface of what? I am confused by what you said.

[ericoporto]

@edwinksl this one https://desktop.github.com

[edwinksl]

@ericoporto This issue is about Atom though, not GitHub Desktop.

[lucascosti]

+1000

After encountering more than a few issues with other unofficial repositories that do rebuilds, I have to again echo a call for official yum/dnf repos!

[edwinksl]

@lucascosti I just read that Fedora supports snaps and there is a snap for Atom (find it using snap find atom).

[ghost]

At least it would be nice if the landing page could show the current version, one has to download the package and install it to check if the version is newer than the installed.

A "Check for updates" option on the Help menu would be much better, but the repository is a MUST

[mightyiam]

Just saying: snaps are the future.

[alex94cp]

Or Flatpak for that matter ;)

[piranna]

Just saying: snaps are the future.

No, it's npm.

[pierriko]

Here is a notification script one could run after startup:

var base_url = "https://github.com/atom/atom/releases";

function check(resolved) {
    console.log(resolved);
    var tag = resolved.split('/').pop(-1);
    var latest = tag.slice(1);
    var current = atom.getVersion();
    if (latest != current) {
        atom.notifications.addInfo("new version available: " + resolved);
    }
}

var request = new XMLHttpRequest();
request.onreadystatechange = function () {
    var DONE = this.DONE || 4;
    if (this.readyState === DONE) {
        check(this.responseURL);
    }
};
request.open('HEAD', base_url + '/latest', true);
request.send(null);

It's based on a python update script I'm using:
https://gist.github.com/pierriko/8f64d64b9d3212d62754

Feel free to create a package out of that.

[nebulousdog]

:+1:

[sudopluto]

https://bintray.com/ seems to be free for oss projects and integrated with github

[isiahmeadows]

@digitalvapor You can always subscribe to the issue. A few of us do find it annoying when we get pinged repeatedly over some popular issue.

[quasipedia]

If anybody is interested, I wrote a small package that checks for newer releases (beta and stable alike, according to settings) and notify the user at startup (or using the check command).

It uses the github API to perform the check, so it's platform independent.

It's my very first package for Atom, so it may be rough around the edges. Feeback on how to improve is welcome though. :)

You can read about it here or install directly with:

apm install geiger

[sherghan]

+1
Fedora repo would allow easier and wider adoption in Linux community.

I still forget that it's not updating itself on Linux (I use all three system versions).

[lucascosti]

Whilst we wait, I can also recommend the atom-up2date package that notifies you of new releases (including showing the notable changes): https://atom.io/packages/up2date

[probonopd]

Why not do an AppImage and be done with it? Many Electron-based apps already do this. There is even a binary delta updater.

[tsimonq2]

Or why not do a Snap and just be done with it?

[probonopd]

Or why not do a Snap and just be done with it?

Because then if won't run on almost all desktop operating systems out-of-the-box. In fact, on almost none. According to Distrowatch:

(...) we already have a cross-platform package format which works. AppImage has been around for years, automatically handles dependencies, truly works across multiple distributions and does not require root/sudo access to install. AppImage requires no additional framework or libraries to be installed, there is no new package manager to learn and AppImage programs can be launched through any distribution's file manager.

[nebulousdog]

is there a plan on going forward from the team?

[bugaevc]

Because then if won't run on almost all desktop operating systems out-of-the-box. In fact, on almost none. According to Distrowatch

While I respect & appreciate the testing effort by Distrowatch, I believe their results are obsolete or plainly wrong. There are clear instructions about enabling/installing both Flatpak (http://flatpak.org/getting.html) and Snappy (http://snapcraft.io/docs/core/install).

Furthermore, Flatpak is shipped out of the box with GNOME 3.22 (in Fedora 25, to be released soon; and in other distros that ship GNOME):

Installing apps in the command line is quite easy, but it’s not the best user experience. In Fedora 25, Flatpak will be fully integrated in GNOME Software and you will just download a .flatpak file, double-click it and Software will take care of the rest.

The other important point is that there should be a Flatpak/Snappy repo with updates from the upstream, as opposed to single packages like those we have now. Is that possible to achieve with AppImage?

[probonopd]

Check AppImageUpdate for binary delta updates directly from upstream.

[quasipedia]

Not that this is going to make a real repo superfluos, but in the last release of geiger we added buttons that link to the download page of the latest packages.

Not ideal, but it's a manual step less to perform.

[jrial]

I fail to see how this is somehow Github's responsibility. The software is open source, it's up to the Debian/Ubuntu/Mint/... maintainers to include it in their repos if they want their users to be able to update it through the package manager. This discussion really belongs on the Debian/Fedora/... lists, IMHO.

[piit79]

@jrial Distributions are well known for not being willing to update packages very often. (This is the case especially for Debian.) This would mean that the packages in the official repos would be out of date. For a project as fast-paced as atom this would make the official packages not very useful.

Many projects provide their own package repositories which ensures users can get new versions quickly and easily. It's very easy to do and automate, so I'm not sure why atom couldn't do it as well...

[cblp]

@piit79 large Debian repositories are maintained by ordinary people. You need to poke them to have software updated.

[piit79]

@cblp Well, with Debian it seems to be a question of policy rather than lack of resources - they seem to include the stable version at time of release and then only include security updates.

And not having to "poke" a third party and hoping something happends is exactly the reason why own repositories would be a much better solution :) Even if there was someone at Debian willing to update atom package with new versions no doubt it would take days to weeks for the new version to get to the repository.

[lesinigo]

@jrial disclaimer: this is all just a big IMHO :-)

GitHub (or atom.io or whoever it is) takes care of distributing installers for macOS and Windows platforms, as well as providing an infrastructure to keep those installs up to date (through in-app updates).

I think you either go the "_here's the source, linux binaries are packager's problem_" way, and do not even provide a DEB/RPM package, or the request for some update mechanism is perfectly legit.
In-app upgrades on RPM/DEB based distros are not usually feasible or easy, and a repository is the logic choice here. Even better: a DEB/RPM package to set up the repository and its stuff (eg. key to verify package signing).

Also, distributions usually have specific goals and release policies for packages in their repos, and I'd bet they do not match Atom ones.

[bugaevc]

I fail to see how this is somehow Github's responsibility. The software is open source, it's up to the Debian/Ubuntu/Mint/... maintainers to include it in their repos if they want their users to be able to update it through the package manager. This discussion really belongs on the Debian/Fedora/... lists, IMHO.

You would not say that it's up to Microsoft & Apple to pre-install Atom and keep it updated via system updates? Atom/Electron/atom.io is managing the update infrastructure on Windows & macOS, and people want them to do the same on Linux.

That being said, things like Flatpak, Snap and AppImage are not only easier for users to install & use, they also are (or intend to be) way easier for developers to create & distribute.

[peteruithoven]

Yeah, please research snap. This would allow atom to release stable, beta and daily releases that should then appear in software centers of recent Linux distributions. As far as I understand it it wouldn't require a user to add another source.

There are issues on this in the Electron package, to create a general Electron solution:
https://github.com/electron-userland/electron-packager/issues/525
https://github.com/electron-userland/electron-builder/issues/509

The Snapcraft mailinglist also responded very positive:
https://lists.ubuntu.com/archives/snapcraft/2016-November/001614.html

[jrial]

You would not say that it's up to Microsoft & Apple to pre-install Atom and keep it updated via system updates?

I rely on Debian to maintain packages for 99% of the stuff I have installed, from vim to thunderbird, from Gnome to the Arduino IDE. So yes, that's exactly how things are done on Linux, minus the "preinstall" part. Microsoft releases an operating system, whereas Debian releases a software distribution.

I also see some misconceptions in this thread regarding how often packages get updated. If you run the "stable" or "LTS" version of your distro, you'll only get sporadic security updates. That's by design. If you want to live on the edge, pick the faster-moving variants (for Debian that would be either Testing or Unstable).

That said, I certainly don't mind having a faster moving PPA for those of us who want to stay up to date. However, if webupd8 is happy to provide this, I don't see why github should duplicate the effort. Perhaps I missed something? I only read the first and last couple of comments on this issue, about 10-20 on either end.

[probonopd]

@jrial while everything you write is true, some users just like to get a Linux-based _operating system_ from their distribution provider and use that as a _platform_ on top of which to run applications directly downloaded from the respective application authors' (upstream) dowload pages.

For example, if a user wants a debian stable operating system, he still may want the latest Arduino application from arduino.cc (my experience has been the Arduino is _always_ outdated in distributions).

After all, this is the model the operating systems with any decent market share on the desktop have been using since decades.

[ericoporto]

@probonopd I don't know what you have been smoking, but last time I checked iOS and Android dominate the market without you ever having to download software from the Internet.

[probonopd]

@ericoporto _desktop_ ;-)

[ericoporto]

A packet manager is better to manage your software, which is why Atom has the APM. You can use Chocolatey on Windows and Brew on Mac, I don't know how well those manage updates. It's a reasonable request a ppa for Ubuntu since the packet manager is the default way to grab software in the distribution.

[bugaevc]

Yes, and now distributions are transitioning to Snaps / Flatpaks as the default ways of installing _apps_.

[dhollinger]

@bugaevc no one has fully transitioned away from package managers yet and that won't change fully for some time. Snaps are only funny stable in Ubuntu and they haven't fully transitioned yet and last I checked, Flatpak was still in alpha or beta stage - no where close to production ready

[bugaevc]

last I checked, Flatpak was still in alpha or beta stage - no where close to production ready

What makes you think it's this way? The major version number is 0, true, but the offcial website never mentions it being not ready. On the contrary, it has been "officially launched" (read this). There are some parts that are not fully ready yet (e.g. portals -- but the basics (more than enough for Atom) are there), but I believe it's very much production ready.

[probonopd]

no one has fully transitioned away from package managers yet

I don't think anyone is suggesting that one should entirely transition away from package managers. They are great for managing the _base system_, the _platform_, on top of which upstream-provided applications can run. At least that's how I think about AppImage.

[dominicbarnes]

I've been using the webupd8 PPA for a while now, but since it has now caused me (and others) a big problem (see #13238) I've been made aware that since this is an unsupported pattern, the recommendation is to avoid it.

If that is indeed the case, the atom team needs to do more to improve this experience for Linux devs. Supporting the most popular package managers (eg: apt, yum) seems to be a very reasonable bare minimum.

[dhollinger]

On the contrary, it has been "officially launched"

A matter of days before that a Red Hat/Fedora Developer wrote a blog (in response to a Snappy Press Release) where he specifically stated:

Neither Snappy nor Flatpak is at all close to being ‘done’, in the sense of being a credible system for cross-platform app distribution with buy-in from software publishers and distributions.
Source

And that is absolutely right. Just because something has been "launched" does not mean it is stable and ready for general use. Both systems are still missing many pieces - part of that being that sandboxing doesn't work properly in X11 (last I heard anyway). To top it off, for both to fully be feature ready, they also have to BOTH work well with AppArmor and SELinux or the security claims of each are pointless as well.

On a final note, Flatpak and Snaps are still not heavily used by Desktop Linux users and they aren't particularly user friendly to setup either. On top of that, Enterprises that "support" Linux Desktops probably won't move away from the core package managers (YUM, APT) for some time. All of this has to be thought about. You try and force users to a new technology too early, they'll just go somewhere else.

[bugaevc]

Fortunately it's not as bad as you think it is ;)

Both systems are still missing many pieces - part of that being that sandboxing doesn't work properly in X11 (last I heard anyway).

Fedora 25 is using Wayland by default, yay! (OTOH Atom will still go through XWayalnd, but that's not directly related to Flatpak).

To top it off, for both to fully be feature ready, they also have to BOTH work well with AppArmor and SELinux or the security claims of each are pointless as well.

I believe Flatpak works fine both on Fedora (SELinux) and Ubuntu (AppArmor), while Snappy needs SELinux disabled (set to not enforcing). And yes, the security is not quite there yet, but we're talking ease of distribution here; let's say we trust the open-source code of Atom (and its developers).

On a final note, Flatpak and Snaps are still not heavily used by Desktop Linux users and they aren't particularly user friendly to setup either.

The former -- yes, unfortunately, yet. The latter -- no, Flatpak is installed by default on F25 and it's integrated into the Software app (https://help.gnome.org/misc/release-notes/3.22/) so that installing an app takes about two clicks.

[probonopd]

I believe Flatpak works fine both on Fedora (SELinux) and Ubuntu (AppArmor), while Snappy needs SELinux disabled (set to not enforcing). And yes, the security is not quite there yet

Check AppImage - works on both Fedora and Ubuntu out-of-the-box, no runtime or prior setup needed.

[Yajo]

Snap, Flatpak and AppImage seem to be best choices for upstream packaging. You forget about the distro (unless you choose Snap :laughing:) and concentrate in the app. Supporting those 3 instead of .deb and .rpm would be a good exercise.

Downstream distros can also package Atom in their packaging format if they want, because it is open source as already claimed.

FWIW, as a workaround, right now I'm subscribed to their releases RSS channel, and reinstall the rpm manually when a new one is available. Not as cool as a repo, but works.

[mattdangerw]

I've just put up a PR adding preliminary flatpak support, for those interested.

https://github.com/atom/atom/pull/13293

[probonopd]

For AppImage support, see my code at https://github.com/atom/atom/issues/4980#issuecomment-250965931

[alexandreleroux]

If it helps justifying the workload associated with maintaining an official PPA for Atom, some employers require/mandate the use of software from official PPAs. It's my case and I'm certainly not alone. Thanks!

[dhollinger]

@alexandreleroux same can be said for Red Hat shops and yum repo requirements. It's actually quite common at places where Linux desktops are available for work as the company wants to control what is put on users' desktops

[sudopluto]

https://github.com/Microsoft/vscode/issues/2973

I made the switch from atom to vscode ages ago.....

vscode is faster / snappier than atom, and they seem to actually give a damn about linux users

[jrial]

@sudopluto This is the Atom issue tracker. And like any other issue tracker, it's a place where users gather to report problems and discuss ways to improve the product it's associated with. What it decidedly isn't though, is a place for latching on to random issues and venting one's frustrations through irrelevant nonsense.

[piit79]

@jrial Agreed.

Although there's no denying it would be very embarrassing if vscode had an official repo before Atom ;)

[sudopluto]

I have been watching this issue for a year and a half. In this time atom hasn't addressed at all or even considered adopting one of the many community repositories available. There is zero communication from the team on this issue tracker, and there has been no progress. Like I honestly do not understand this. GitHub already has a package cloud repo for their git lfs, yet they can't do the same for atom?

[lee-dohm]

@sudopluto You are correct, we haven't addressed this Issue. That is why this Issue is still open. It is something that we would like to address, which is also why it is still open. There have been lots of other things that have, in our opinion, been a higher priority than addressing this given the handful of people that we have to work on Atom. I'm sure that everyone that posts here will disagree with our choices of prioritization at some level or another, that's simply the nature of the beast. If VSCode is better for you, then I'm glad that you've found something that works for you.

For others who might be interested in actually helping with this, I did ask for help in finding something that would make creating our own package repository simple and have received no response:

https://discuss.atom.io/t/why-isnt-atom-in-any-official-repository/29294/13?u=leedohm

I've also heard about Flatpak and its ilk but we're not excited about having to support several _more_ methods of packaging Atom for Linux in addition to the ones we've already committed to. Until Flatpak et al completely supplant the tried-and-true methods of packaging, we're probably going to stick with the packaging setups we have now.

[sudopluto]

@lee-dohm I poked around in the git-lfs repo, and found this script for package cloud: https://github.com/git-lfs/git-lfs/blob/master/script/packagecloud.rb. I think after the build is done, someone manually runs this to push the new package to the repository.

[Akronix]

Do you remember those old times in Windows, when you had to go to your program provider website in order to download latest version of software and keep them up-to-date?

So now, we all, Linux users, are back to those happy days thanks to Electron! :car:

[bugaevc]

@Akronix

Do you remember those old times in Windows, when you had to go to your program provider website in order to download latest version of software and keep them up-to-date?

So now, we all, Linux users, are back to those happy days thanks to Electron! 🚗

What? No. Electron's not to blame. For one thing, Windows still doesn't have a built-in solution for [Win32] app updates (or if there is one, it's not being used) -- the situation only became better because most apps found some hackish way to update themselves, including Chrome famously installing itself into user's AppData directory to skip UAC prompts, and Flash Player shipping a separate updater mini-app that's hanging in the system tray distracting users.

Fortunately, Linux has a solution for app updates -- be it traditional package managers or Snap/Flatpak -- that does not involve hacks on the app's side. Even Chrome on Linux installs itself system-wide and gets updates from its repo by the means of the package manager. I'm thankful Electron doesn't have a built-in mechanism for updating on Linux. Whatever app people create with Electron can then be packaged and shipped in various ways. If they chose to distribute individual packages (like they do with Atom), we have to download each version as you describe. If they set up a repo that would be updated when new versions come out, then we'll get updates automatically, in a native-to-the-system way -- again, nothing to do with Electron.

It's just the same situation as on Android. You can distribute individual APKs and make people download & install each version manually, or you can publish your app into a store like Google Play Store and let people get updates automatically & easily. But it has nothing to do with Java and the Android Framework.

[isiahmeadows]

Please remain aware that each message results in emailing and notifying at least 73 people (this isn't counting those actually subscribed, but haven't actually said anything in the issue). I'd find it much easier to track the status of this issue when the signal-to-noise ratio is low, and getting pinged multiple times a week over a comment isn't going to help that much.

[Akronix]

@bugaevc Ok, then why mac users are getting automatic updates if MAC OS X has its own updater system?

This is what happens in practise: Mac and windows users are being automatically updated but Linux users are not. And this is not typical for the bunch of apps I'm running on my Linux system, just electron apps (and maybe some rather rare one) are the ones I have to update by hand.

[50Wliu]

@Akronix This issue is specific to Atom not being officially distributed on any Linux software repository. If you have an issue with the Electron update process in general, please file an issue on the Electron repository instead. Thanks.

[sudopluto]

@50Wliu any word on using the package cloud script that git-lfs uses?

[lee-dohm]

@isiahmeadows is correct, this has gotten completely off topic. If people want to discuss things not directly related to this Issue, please move them to some other venue.

@sudopluto No, still no update because nobody has had time to work on it. When we get the chance to work on it, we'll post an update.

[dhollinger]

@lee-dohm In the meantime is there anyway to at least get something that will phone home and check for an update to Atom? That way, I'm not 6 versions out of date before I realize there's been a new release.

[lee-dohm]

@dhollinger There are a couple topics like this one on the Discuss forum with auto-updating shell scripts. You may want to take a look at them and see which one works best for you.

[Akronix]

@dhollinger As already said in this post, you can use geiger package to get notified when new versions are released.

[fusion809]

A major competitor of Atom — Visual Studio Code (VSCode) now has its own official Linux repositories (both Debian and RPM package repos). Not sure if anyone else shares this opinion, but in my opinion, this fact (along with the fact Atom still doesn't have its own official Linux repositories) makes Atom look like an inferior product or at least, an inferiorly-distributed product. Especially seeing how Atom is older than VSCode! Can we please fix this source of embarassment?

[sudopluto]

Unwatching this bug after waiting for two years. It's not gonna happen folks. If you are on ubuntu you can try ubuntu make. Or you can just switch to vscode like I have.

[fusion809]

@sudopluto I agree it seems like Linux will always be the underdog of the officially supported platforms of Atom, without an official auto-update mechanism, although I've developed a preference for Vim as an Atom alternative. Faster, uses less RAM and like a beloved pet will follow you anywhere (any operating system, any instruction set architecture, any user interface [graphical vs. command-line], etc.).

[treb0r]

There is a perfectly usable ppa for Ubuntu. Just search for it.

[fusion809]

Yeah but it's unofficial and usually lags behind by at least a day behind the latest releases. Atom also has an unofficial Copr for Fedora but it also tends to lag behind a little behind the latest releases of Atom.

[treb0r]

I can live with a day. If I really needed it fresher than that I would build it from source.

I know people who use Arch who do exactly that.

[fusion809]

At least a day, usually it's more than a day. Like the 1.13.x series of Atom was never even packaged by that PPA, rofl. So for over a month it was out-of-date.

[treb0r]

Well this is open source software. If you feel strongly then help to sort it out. Start a ppa even.

I suspect that the emerging snap/flatpack approach will make packaging software for multiple Linux distributions much more straightforward.

There is always the option from building from source too.

[fusion809]

The solution I am here supporting is not an unofficial PPA for Atom, which you seem to prefer, but that the Atom development team provide their own official Linux repositories for Atom, like VSCode's developers have for VSCode. I already have my own way of keeping Atom up-to-date using shell scripts. Users with less skill with shell scripting won't have that option, hence why an official Atom Linux repos are likely the best solution for everyone.

[treb0r]

No I don't prefer unofficial ppas. I can however see the challenges and costs of supporting multiple Linux distributions and versions. Once snaps or flatpacks or similar become mature it should make the distribution of Linux software much simpler. When that happens I'm sure Atom will provide an official package.

In the meantime I personally am grateful for Atom given I don't pay anything for it so I'm happy with the way things stand.

[fusion809]

Oh and I already provide a cross-distribution Linux package for Atom, specifically an AppImage https://bintray.com/fusion809/AppImages/Atom#files. I update it regularly. The only things it needs to be run are:

• A 64-bit Linux distro with at least version 2.14 of glibc
• FUSE setup.

[treb0r]

Well that sounds great 😀.

Surely the way forward?

[fusion809]

Well it doesn't have an auto-update feature though. Every new release ya have to re-download it, unless @probonopd (the original and lead developer of the AppImage format) can offer a solution. I have heard of delta downloads, is it possible for me to add an auto-update feature to this AppImage?

[probonopd]

Absolutely, shouldn't be much of a problem.

[treb0r]

Well I've no experience of AppImage but I've played with snaps and they do support updates.

I'm going to read up on AppImage..

[fusion809]

Ironically they're older than both snaps and flatpaks. I've added a new issue on creating an auto-updating AppImage for Atom, per the above issue reference.

[probonopd]

A really large number of Electron-based and other applications are distributed in AppImage format for Linux these days: https://github.com/probonopd/AppImageKit/wiki/AppImages

electron-builder has native support for generating AppImage files; in fact, it has been the default for the Linux platform for quite some time now.

[ghisvail]

Visual Studio Code (VSCode) now has its own official Linux repositories (both Debian and RPM package repos)

That's enough a reason to chose VSCode over Atom if you running a DEB or RPM-based Linux distribution. It is very convenient to install the package once, and then let your package manager handle the updates automatically. If Microsoft can do it for VSCode, I wonder why this cannot be done for Atom.

A really large number of Electron-based and other applications are distributed in AppImage format

Flatpak is getting a lot of traction these days, and support desirable features such as auto-updates. See this discussion.

[isiahmeadows]

May I note that each and every message here hits 76 people with both a notification and an email?

[donlencho]

correction: 75 people, I'm out of here, this has become ridiculous.

[marcelomendes]

I'm one of those that are switching to vscode, due to the packaging support.

PS: This kind of thread reminds me of this https://github.com/adobe/brackets/issues/10255

[guoyunhe]

I am also looking for an official RPM repository for Linux. It would be great and it is not a hard task. Microsoft provides VS Code repository for a long time. It is really a great experience: you do not to download package from web page manually every month.

[mlcdf]

Atom is now available as a snap package:
sudo snap install --classic atom

The only problem with this install, is that Atom doesn't start in a independent process by default. You have to do atom & every time...

(Tested on Linux Mint 18.1)

[quasipedia]

Is this an official distribution maintained by the folk at GitHub, or still the Nth unofficial one, maintained by some good-willed person?

[luispabon]

The snap seems to work well on Ubuntu, thank you :+1:

[fusion809]

If it was developed by Atom's development team I'd expect a member of Atom's development team to be announcing it here.

[Yanpas]

Answering one of the first comments, Chrome's deb package installs chrome repository to system along with chrome itself. I think it won't be a big headache to do the same with atom

[lee-dohm]

@quasipedia It is not maintained by GitHub team.

[PHLAK]

Chiming in to request an official PPA for Atom on Ubuntu. I don't want to rely on some third-party repo and manually updating is tiring.

[peteruithoven]

Elementary just released their new AppStore, maybe that's interesting?
https://developer.elementary.io/
https://medium.com/elementaryos/building-the-future-of-elementary-os-9df3fa940b67
https://medium.com/elementaryos/new-release-elementary-os-loki-0-4-1-2a756549ee76

[rolandixor]

Snaps have a long way to go before they can be as useful as a debian package. For starters, the sandboxing snaps use means that sometimes a program cannot anything outside the sandbox, so it will not recognize that other applications are installed (for example, if you want to open a file in your browser from within a "snapped" app.

Not only not an ideal solution, but a bad one.

[santhosh74]

can Anyone eplain the tasks involved in soving issue:: Add Repo During Install of Deb Package for Automatic Updates

[rastersoft]

Just a note: I think it should be enough to create the repositories. Atom is an editor for programmers, and I'm pretty sure that a programmer knows how to add an extra repository to his/her system.

I just comment that in case the problem is in creating the code that automagically adds the repository in the system when the package is installed. It makes sense with Chrome because that is a software for everyone, but I think that is not the case for Atom.

This also has the advantage of avoiding problems with people who don't want foreign repositories in their systems...

[carwyn]

More up to date Fedora COPR, still lags a little behind though:
https://copr.fedorainfracloud.org/coprs/mosquito/atom/

[lee-dohm]

@nextgenthemes your comment was deleted as a violation of the Atom Code of Conduct as it was insulting or derogatory. You may consider this an official warning.

[ghisvail]

Despite the rudeness of @nextgenthemes comment, his point remains valid. No proper update channels via an official Debian repository or snap package is a problem. I had to personally request updates to the community maintained snap package.

Meanwhile, vscode maintains an official Debian repository and is in the process of releasing an official snap package. Just saying.

[lee-dohm]

No proper update channels via an official Debian repository or snap package is a problem.

I agree, that's why this issue exists and is still open.

Also though, if someone's point is valid, then they don't need to be abusive in delivering it. The Atom maintainer team has lots of work to do, it is true. We're here to work with people who want to work with us to make something awesome. In the wise words of Lieutenant General Jay Silvera, superintendent of the US Air Force Academy:

If you can't treat someone with dignity and respect, then you need to get out.

And for the record, I appreciate your ability @ghisvail to express your frustration without resorting to rudeness.

[ghisvail]

Also though, if someone's point is valid, then they don't need to be abusive in delivering it.

Totally agreed. Hence myself focusing on constructive arguments.

I appreciate your ability @ghisvail to express your frustration without resorting to rudeness.

You're very welcome. I am also in touch with the snapcrafters team which maintains the unofficial snap packaging. Ideally, it would be to converge to something more streamlined in the short future.

[PHLAK]

After the recent discussions and obvious user frustration I have to ask, is there a technical reason this can't happen at the moment (it doesn't seem like it)? If not, what would it take to get this prioritized?

[lee-dohm]

The technical reason is that nobody on the Atom team is familiar with the process to set up the various auto-update infrastructures for .deb and .rpm using distributions. Snap and the like are useful for an even smaller subset of the Atom Linux user base than what we have now, so we're reluctant to go "all in" on any one of those. And supporting all of them is not sustainable for us.

We can reliably produce .deb and .rpm packages, obviously. What we need is step-by-step instructions on how to go from there to auto-update distribution endpoint for both package types in a day or less. If someone can supply that so that a Linux newbie like me can get it up and running, then I'm willing to give it a shot.

But it seems that @paulcarroty has supplied us with just that, so I'll have the team take a look.

[PHLAK]

What @paulcarroty put together looks decent enough. If that doesn't work out I've done some work with aptly in the past and it was relatively painless (I didn't originally set it up, only used it afterward) but this was also a few years ago. The major downside is that it doesn't support .rpm packages (AFAIK).

See: https://www.aptly.info/tutorial/repo/ and https://www.aptly.info/doc/aptly/repo/add/

[carwyn]

Both the main RPM distros have platforms for build and distribution that could be used:

https://copr.fedorainfracloud.org/
https://build.opensuse.org/

(Launchpad can do the same for Ubuntu)

Alternatively there are docs on how to build a hosted repo here:

https://github.com/rpm-software-management/createrepo
http://yum.baseurl.org/wiki/RepoCreate
https://wiki.centos.org/HowTos/CreateLocalRepos

Arguably though given that atom (and vscode) will no doubt want to ship more frequently than the underlying distros and have their own dependency characteristics flatpak and snap are the intended solutions for this, even if not widely adopted yet.

[paulcarroty]

@carwyn why OBS, Copr, Launchpad and other distro-specific services is bad in this case, the quotes of SUSE Chairman:

If Atom had a build process that didn't need to download random crap from the internet I'd love to see it officially in openSUSE
How does that in any way verify anything? The build program could've downloaded malware for all I care, and it'd just as happily log the exact same thing.
That's what we do for Python, Ruby, and every other language. If a program depends on a dozen things, we package those dozen things independently. The fact that Node makes this a living hell is not openSUSE's fault.

Shortly, the classic Linux build services only supports the build process without Internet connection. Atom use a lot npm packages with unstable dependencies, create the needed tarball with all sources for each release isn't easy.

@lee-dohm I've added more comments. That's not the work for Senior DevOps Engineer, a boy from school will be enough :)

[DanScharon]

Shortly, the classic Linux build services only supports the build process without Internet connection. Atom use a lot npm packages with unstable dependencies, create the needed tarball with all sources for each release isn't easy.

That's why I'd rather have a flatpak for Atom (Snap is too much Ubuntu-centric in my eyes)

[ghisvail]

Snap is too much Ubuntu-centric in my eyes

I am sorry what?

[DanScharon]

@ghisvail

1. developers have to sign a CLA if they want to work on snap
2. snap has only one repo hardcoded (hosted by canonical). You can't use several different repos like in flatpak (e.g. flathub and gnome-apps)

[jrial]

@paulcarroty are these derogatory jabs at the Atom team really necessary?

I quote:

Why is it so hard to do it for the Atom Team? ~30 lines of code!

from here. And

That's not the work for Senior DevOps Engineer, a boy from school will be enough :)

in this thread. And I believe I saw another one which expressed a similar sentiment, although I could be mistaken.

[EDIT] Nope, here it is:

Could never understand why it’s so hard to do for the Atom team - less than 50 lines of Bash code.

These folks put a lot of effort into a piece of software which they share freely with the world. They deserve better than to constantly being attacked for the things that go wrong or that haven't been finished yet.

We now have a FOSS editor which is easy to hack, has an extensive ecosystem of useful packages, and is mature enough to use as our main development tool. Compared to that, I think a few annoyances like the occasional bug or lack of official repositories are minor issues and not something deserving of these below-the-belt remarks.

[ghisvail]

developers have to sign a CLA if they want to work on snap

And?

You can't use several different repos like in flatpak

And?

Does the end-user care?

Both flatpak and snap are worth considering from a technological merit. As an end-user however, the fact is I can install a reasonably up-to-date version of Atom via snap today. Can I do the same with flatpak, maybe?

[treb0r]

I completely agree with @jrial.

Atom is great and we need to see some respect for those who put their time and effort towards making it so.

The bad attitude of some on this thread is not at all helpful.

[fusion809]

Well Atom already has a cross-distribution package, besides the tarball. NixOS has an Atom package in their official repositories and their package manager, Nix, can be used on any Linux distribution. I've even used it to install packages on my Arch Linux system when the Arch (pacman-installed) packages have things wrong with them.

[fusion809]

@paulcarroty Copr actually does allow packages internet access during the build (although you do have to enable it manually), that's why there's a few Atom packages provided by Coprs like https://copr.fedorainfracloud.org/coprs/mosquito/atom/.

[akashnimare]

Well, I've setup the apt repo on bintray for Zulip's linux client. Here - https://bintray.com/zulip/debian/zulip-electron
@lee-dohm I can help you out if you want.

[DanScharon]

@ghisvail
a CLA means Canonical can change the license terms any time. This introduces a kind of uncertainty concerning the sustainability of snap (similar to the situation at ownCloud that led to its fork Nextcloud).

Does the end-user care?

The end-user cares about being able to get the latest software release. S/he doesn't want to change technologies all the time to get the software. With snap being dependent on Canonical's goodwill (license- and infrastructure-wise) it doesn't sound like a sustainable solution at the moment. Just think of Mir and Upstart and how many technology changes it meant for Ubuntu users in the end.

Both flatpak and snap are worth considering from a technological merit.

Yes, but that is not my point. Atom can/should be offered within both formats, but only offering it as a snap and not as flatpak doesn't make sense in my eyes.

Can I do the same with flatpak, maybe?

This is not integrated into a flatpak repo so a user is still stuck with updating manually.

[ghisvail]

[...] This introduces a kind of uncertainty concerning the sustainability of snap

I don't buy it, sorry. Your statement is speculative at best, if not edging towards FUD.

The end-user cares about being able to get the latest software release

Which both snap and flatpak are designed to provide, correct?

The rest of your point (your personal assessment of Canonical's past failures and infrastructure) is purely subjective. Meanwhile, similar software such as Microsoft vscode and jetbrains intellij and pycharm are now installable via snap. It seems these major companies do not share your concerns about Canonical.

Atom can/should be offered within both formats, but only offering it as a snap and not as flatpak doesn't make sense in my eyes.

The Atom snap is essentially ready for integration with upstream, thanks to the work from the snapcrafters community. The same happened to vscode, whereby this very same community did the initial investment, and then helped integrate snap builds within the upstream release process.

How much work would be required to achieve the same with flatpak?

This is not integrated into a flatpak repo so a user is still stuck with updating manually.

So much for transparent updates then, which is the topic of this issue I reckon.

[DanScharon]

@ghisvail I never said there shouldn't be snaps for Atom. I said there should be both, snaps and flatpaks. Do you really have any objections to having both?
There are several examples of Canonical's failures (Mir, Upstart and now Unity) and they all suffered from NIH-ism and not making it part of a greater community effort. Unfortunately I see the same happening with snap. I'd be happy if it doesn't turn out the same way

So much for transparent updates then, which is the topic of this issue I reckon.

huh? It's only one commit and one pull request from https://github.com/flathub/flathub/ (or other repos) away.

[adityashah1212]

The current issue with flatpak-builder (tool that automates flatpak building, also used by flathub bot) is that it still doesn't directly support custom installers such as npm/pip/yarn... When this feature is support I am certain that someone will make the pull request for atom ( If no else does I surely will :P). Have I look at https://github.com/flatpak/flatpak-builder/issues/15.

[ghisvail]

I never said there shouldn't be snaps for Atom.

Quoting yourself earlier (emphasis added):

I'd rather have a flatpak for Atom

If not said explicitly, that's strongly implied please.

Do you really have any objections to having both?

I don't. I am just questioning the amount of work required to integrate flatpak upstream. So far, your arguments have been focused on ideology and your personal assessment of technical merit.

There are several examples of Canonical's [...]

Ideology and personal assessment again...

Meanwhile, I have been asking essential questions which have yet to be answered. Can you install a recent version of Atom with flatpak today, and would the resulting packaging files be easy to integrate to the upstream release process? Perhaps @adityashah1212 could answer these.

[adityashah1212]

Can you install a recent version of Atom with flatpak today

No you can't

would the resulting packaging files be easy to integrate to the upstream release process

Yes, since it is just one json (about 100 lines maybe, possibly even less).

[adityashah1212]

As far as my opinion of snaps, there are a few fundamental gliches
1) It relies on AppArmor for sandboxing, thus any distribution not having AppArmor is going to run a snap without a sandbox. Which in itself proves that it doesn't provide the same environment across all linux distributions which is supposed to be its primary goal. Comparing flatpak to it, even though it relies on kernel namespaces (which is not be supported by all distributions), it still provides fall back to setuid based sandboxing

2) Size of the app, I don't know the current state but if I remember correctly firefox snap turned out to be 1GB... thats insane. It may not be that big anymore, but there is no concept of runtime, thus every application carries everything, thus bloating it. Flatpak has 3 main runtimes, namely freedesktop (bare minimum libraries), gnome (suitable for gnome and gtk based application) adn kde (suitable for kde and qt applications). Also it uses ostree to deduplicate files even across applications.

3) I also remember reading, Canonical asks you to sign contributors agreement when contributing to snaps and their repo (really questionable in open source world).

Advantages of snaps
1) It can deploy server grade application, while flatpaks are only meant for desktop gui applications. But again why do you need snaps on servers, you can always use docker.

[ghisvail]

Can you install a recent version of Atom with flatpak today

No you can't

AFAIC, the discussion should just stop right here.

It relies on AppArmor for sandboxing [...]

Irrelevant. The topic of this issue is on updates, not sandboxing.

Size of the app

snap info atom tells me the Atom v1.21.1 snap is 181MB in size. Sounds reasonable to me, what do you think?

FYI:
snap info intellij-idea-community -> 419MB
snap info pycharm-community -> 189MB

I'd be curious to hear which sizes are achieved with flatpak for these 3 apps.

if I remember correctly firefox snap turned out to be 1GB... thats insane

snap find firefox yields nothing. No idea where you got your numbers.

there is no concept of runtime [...]. Also it uses ostree to deduplicate files even across applications.

I'll ask again: does the average user care? What does it have to do with updates?

Canonical asks you to sign contributors agreement [...]

Same question: does the average user care? What does it have to do with updates?

Personally, as long as I can simply run snap install (or flatpak install) and have transparent updates provided by upstream, I don't mind the underlying piece of technology providing it. Nix packages (mentioned earlier) also look interesting.

[iainhallam]

The discussion seems to have drifted somewhat - I think the original thread was to get the existing .deb and .rpm files into a repo form so that auto-updates could work using the existing mechanisms built into the OS. Snap and Flatpak support (or any other package formats) seem to me like they should be separate issues for each new format.

[isiahmeadows]

@iainhallam Thank you, and I agree. Could we please try to limit discussion a little, since there's a lot of people subscribed to this issue? Also, for the discussion we do have, can we keep it specifically to stuff that will work with what is packaged within distros, like APT, RPM, and friends?

[fusion809]

For Flatpak this separate issue is #11837 (#13293 is a pull request related to this). For AppImages it is #13118. Can't find one for Snap.

[SISheogorath]

Seriously?!? This issue is >3 years old and nothing happened. Still no official repository.

I check the repository, there were multiple PoCs for pushing to repositories.
https://github.com/atom/atom/issues/15901 https://github.com/atom/atom/pull/9425 https://copr.fedoraproject.org/coprs/helber/atom/

There are so many attempts to make this happen, everywhere: https://discuss.atom.io/t/why-isnt-atom-in-any-official-repository/29294/15?u=sheogorath

You already have RPM and DEB files. All you need to do is sign and push them to some kind of provider.

Sign RPM
Sign DEB
Push them to packagecloud from TravisCI

I really don't see the problem. That's less than 4 hours of work, including debugging. And what do we get out of it? Security! And an issue with more than 200 comments and way more supporters solved.

Atom is such a wonderful project and I understand that there are sometimes more important topics, but implementing this are less than 10 lines of code in your .travis.yml and adding one or two signing keys somewhere. It's not like you need to invent anything. Of course, there are more places than packagecloud to host your packages, but it's one of the simplest ways and they provide all needed docs in place.

And if it's still too much work to do this, please tell what you need to provide this so we can help to provide it. Because it would really, really help to keep our Atom setups up to date and prevents hundreds from people from reinventing the update process, like writing ugly shell scripts that run as cronjobs or systemd.timers to check if there is a new atom version.

Thanks a lot and please provide a little bit of attention to make this happen.

[paulcarroty]

@SISheogorath the packagecloud or other services isn't needed, because I'm already done this work - atom-rpm-deb-mirror.

And please stop posting the HOWTOs. You think the Atom developers is too stupid to find info in Google since 3 years of feature request? LOL. They just do not want to do it and probably laugh from these comments. Your and other peoples emotional shit is not more than screaming in emptiness - the truth which you can't see. I thinks the sad truth is much better than years of broken dreams.

[SISheogorath]

@paulcarroty The how-tos weren't about "Here take this and you are happy", it was a proof of my argument that it's not that hard to sign the packages and provide them in a repository.

And yes, I saw your project and as you may notice, it's indirectly linked in the comment.

My point is: As it is not that hard, it would be nice to just make it happen or close the issue as won't fix.

But the official statement was: "We have not enough time to do this" which leads to my point that it's not that hard.

And your repository still doesn't provide signed RPM builds. your repos are signed, but not the packages since you provide them 1:1. And the other way around is way more important because signed packages can be mirrored without losing any trust.

[quasipedia]

@paulcarroty - When in a hole... stop digging!!!

What you call "emotional shit [that] is not more than screaming in emptiness", was a pretty much excellent summary of where we are at. A 3 years old ticket that takes very little time to implement, delivers tremendous value to GNU/Linux users, and on which - most importantly - GitHub failed to communicate properly.

It was clearly also meant to "sting" GitHub devs enough for them to wake up and either make this happen or explain why it won't fix (chances of the post being effective at that: low. But I'm happy to take the risk of wasting 20 seconds of my time reading @SISheogorath post if there is even a small chance of it working).

Since you seem to have misunderstood how the security model on package repositories is supposed to work (something that @SISheogorath attracted your attention on in their closing paragraph, and that is highlighted even more from your subsequent reply) I understand that you may not appreciate fully while none of the workarounds posted so far (from yours to mine) can be considered "good enough" and while some of us cant't believe this hasn't been done already. Your lack of understanding is not a good reason to be rude or shutting other people up though.

[luispabon]

Indeed. The problem is trust that the app you're downloading hasn't been tampered with, and the only real way to trust that is via official repositories.

Atom has access to your ssh keys, your github account, etc.

[tribut]

Can somebody please lock this issue? There are almost 100 subscribers and it seems evident that all of the necessary information has been exchanged.

[paulcarroty]

Since you seem to have misunderstood how the security model on package repositories

No, I completely understand that unsigned packages is bad for security. From another side, RPM and DEB repos has built-in hash sums control which guaranties the integrity of downloaded packages.

The code still open - let's suggest the better model.

[luispabon]

hash_sum !== trust. I can't trust you haven't been messing with the code before building it.

I'm not saying that you have.

[Serkan-devel]

50Wliu deleted a comment from zalew16

Oh and packages on debian should slowly be built reproducible.

[kolAflash]

Duplicate #16317 was mine. So sorry I didn't see this before. Here are some of my core arguments from #16317:

• The recent XSS vulnerability in Atom has been a reminder, that repos for automatic updates are needed. (https://statuscode.ch/2017/11/from-markdown-to-rce-in-atom/)
• Atom should ask the user on the first startup, to add the repo to the package manager. (also having an setting option to undo/redo that) Adding the repo then would mostly be an xdg-su -c '...' command.
• I though about asking some major Linux distros to include Atom in their own repos. But on the one hand that would be a lot of distros and they wouldn't deliver all those Atom updates being publishes while their distro is in stable state. And on the other hand all that's needed to be done for the Atom project to run repos is providing one repo for rpm, one repo for deb and put in the already existing atom-amd64.deb and atom.x86_64.rpm files. As long as Atom doesn't need custom rpm/deb files for every distro (and it doesn't looks like it does: https://github.com/atom/atom/releases), one repo for rpm and one for deb is all that's needed.

[Serkan-devel]

Or just one Appimage that can run on every distribution. It somehow got rejected.

[quasipedia]

@Serkan-devel - ...and for a hoist excellent reasons, given that this issue is about adding software repositories, honouring the dependency and trust models of linux distros, and others have already remarked on how the conversation derailed. :)

I suggest you open/follow another issue if you would like portable installations (Flatpack, Appimage, Snap...). The two have close to nothing in common and I definitively won't delve in a comparison of their merits here... but most definitively "Appimage" (and Flatpack, and Snap, and...) is the wrong answer in this conversation. ;)

[daviwil]

Hey everyone, early Christmas present from the Atom team: official Linux package repositories for .deb and .rpm based distributions! You can check out the updated Linux installation steps in the Flight Manual to learn how to set this up. Please give these package repositories a spin and let us know how they work out for you.

Thanks a lot for all the great feedback!

[quasipedia]

Works flawlessly on Fedora 27 64bit. Marry Christmas (Happy holidays?) to the Atom team too! 🙇 💜 💯

[SISheogorath]

Thanks a lot for this early but wonderful Christmas present! Merry Christmas and a happy new year to the Atom Team!

[luispabon]

:tada:

[fusion809]

Thank you Atom team. It may have taken almost three and a half years but let us not complain about the past but be grateful for the present.

[exploide]

@daviwil Really awesome, thanks! :+1: But two points to note:

• The advertised repo file for RedHat/Fedora contains the line gpgcheck=0. This disables GPG verification for the atom package, see https://access.redhat.com/blogs/766093/posts/1976693 ... All standard repositories on a Fedora system have gpgcheck=1 and I think it's advisable to also have this for the atom repository. (EDIT: it seems the package itself is not signed, yet, so setting this manually to 1 leads to failures at the moment)
• The discoverability of the new repositories is not optimal, yet. One needs to dive into the flight manual, but most users probably just download the standalone deb/rpm from the landing page. Maybe it's a good idea to adapt this install workflow by linking directly to the flight manual or by introducing explanatory "overlay-popups" like Signal does (click "Signal for Debian-based Linux") https://signal.org/download/

[daviwil]

Hey @exploide, thanks a lot for the feedback and additional details! Addressing these two items:

• Yep, you're right, we currently don't GPG sign the RPM packages. I've filed issue #16499 to get this done in the future.
• I agree completely, this is another thing I wanted to do but forgot to file an issue for it. Just created #16498 to track it.

[Superdanby]

Fedora 28 is not supported yet. :cry:

[fusion809]

@Superdanby Not exactly surprising is it given that Fedora 28 hasn't been officially released yet? It's just preview releases that are available.