Bug 1132661 - Review Request: atom - Atom editor from github
Review Request: atom - Atom editor from github
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: Package Review (Show other bugs)
rawhide
All Linux
unspecified Severity medium
: ---
: ---
Assigned To: Nobody's working on this, feel free to take it
Fedora Extras Quality Assurance
: Reopened
Depends On:
Blocks: FE-DEADREVIEW
  Show dependency treegraph
 
Reported: 2014-08-21 15:09 EDT by Helber Maciel Guerra
Modified: 2017-08-25 15:27 EDT (History)
34 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2017-03-29 21:04:29 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Helber Maciel Guerra 2014-08-21 15:09:49 EDT
Spec URL: http://www.hmg.eti.br/static/rpm/nodejs-atom.spec
SRPM URL: http://www.hmg.eti.br/static/rpm/nodejs-atom-0.123.0-1.fc20.src.rpm
Description: This is a open source editor from github. I just create a rpm compiling package based on nodejs and grunt build. moving library to sub-package.

https://atom.io/
https://github.com/atom/atom

I would appreciate a review so that i can get into Fedora!

If you got errors building this source package probably you need new version of gyp compiler. I just create another package updating the old one, based on gyp-0.1-0.11.1617svn.fc20.src.rpm

http://www.hmg.eti.br/static/rpm/gyp.spec
http://www.hmg.eti.br/static/rpm/gyp-0.1-0.11.1967svn.fc20.noarch.rpm
http://www.hmg.eti.br/static/rpm/gyp-0.1-0.11.1967svn.fc20.src.rpm

Fedora Account System Username: helber
Comment 1 Erik Schilling 2014-08-22 10:46:30 EDT
Just a random question: Why not simply call it "atom"?

At least for me it more sounded like a nodejs package while it is in fact a full application... So I would not even need to know about the fact that nodejs runs all this if i just use it...

Just my 2 cent and only my opinion. Do not take this as a too strong recommendation ;)

Regards,
Erik
Comment 2 Helber Maciel Guerra 2014-08-22 15:37:24 EDT
(In reply to Erik Schilling from comment #1)
> Just a random question: Why not simply call it "atom"?
> 
> At least for me it more sounded like a nodejs package while it is in fact a
> full application... So I would not even need to know about the fact that
> nodejs runs all this if i just use it...
> 
> Just my 2 cent and only my opinion. Do not take this as a too strong
> recommendation ;)
> 
> Regards,
> Erik

Good point.
This peace of software is based on chrome, and nodejs (coffescript, js).
But as editor is more clear atom.
I will change package name to atom.


Regards,
Helber
Comment 4 Helber Maciel Guerra 2014-08-27 13:34:02 EDT
Spec URL: http://www.hmg.eti.br/static/rpm/atom.spec
SRPM URL: http://www.hmg.eti.br/static/rpm/atom-0.124.0-1.fc20.src.rpm

I change the spec and submit to fedora copr.
https://copr.fedoraproject.org/coprs/helber/atom/

Regards, Helber
Comment 5 Christopher Meng 2014-08-27 20:41:13 EDT
You shouldn't "install -pm755 %{buildroot}%{_datadir}/atom/libudev.so.0 %{buildroot}%{_libdir}". It's dangerous.

This package is full of craps and bundled libraries. Your copr also failed to build the latest as well. As Fedora doesn't have that version of gyp. Please, next time don't use your custom repo to build the dependencies.

I don't think this package could be easily reviewed and get passed.
Comment 6 Michael Schwendt 2015-01-14 03:13:02 EST
> probably you need new version of gyp compiler.

That's what should be worked on first:
http://bugz.fedoraproject.org/gyp

Figure out whether a new version is needed, then submit an update request ticket in bugzilla and make it block this review ticket. Becoming a co-maintainer of "gyp" would also be one of the ways to get sponsored:
https://fedoraproject.org/wiki/How_to_get_sponsored_into_the_packager_group

[...]

About this review request.

Start with pointing the fedora-review tool at this ticket:

  fedora-review -b 1132661

If you follow the documentation for new packagers, the tool will evaluate the "Spec URL:" and "SRPM URL:" lines, do a test-build of the package and check many things. It isn't a full review, but very often finds issues. It also runs rpmlint on all packages, which is a MUST during review anyway


> # Install gyp
> svn co http://gyp.googlecode.com/svn/trunk gyp

That's won't work. The Fedora Build System (http://koji.fedoraproject.org/koji/ and with Mock as build tool) does not permit accessing the network.


> %package libs
> Summary: Library to chromium
> Group: Development/Libraries

Runtime (!) libs have been in group "System Environment/Libraries" for many years. The Group tag is optional nowadays, however.
https://fedoraproject.org/wiki/Packaging:Guidelines#Group_tag


> Requires:       %{name}-libs = %{version}

https://fedoraproject.org/wiki/Packaging:Guidelines#Requiring_Base_Package


> %description libs
> Libraries need for atom

This needs an explanation. Why does it need and include libudev.so.0 while Fedora's udev is at libudev.so.1 already. This is pretty much a blocker, not just because of the no-bundling policy:
https://fedoraproject.org/wiki/Packaging:No_Bundled_Libraries

It also makes no sense to ship runtime libs in a -libs subpackage just for fun. If they are a strict requirement at runtime and there is no public API either, a subpackage is the wrong choice. Nothing else would need that subpackage.


> Requires:       nodejs
> Requires:       http-parser
> Requires:       zsh

Uncommented explicit Requires are a major source of errors:
https://fedoraproject.org/wiki/Packaging:Guidelines#Explicit_Requires

Too often, packagers either don't keep these requirements up-to-date, or the required packages don't really include want is needed (subpackages or changed versions and contents), or the software must be patched to fix paths.

Add comment in spec files more often than not.


> %install
> #rm -rf $RPM_BUILD_ROOT
> CFLAGS='%{optflags} -g -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64' ; export CFLAGS
> CXXFLAGS='%{optflags} -g -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64' ; export CXXFLAGS

Why do you need CFLAGS and CXXFLAGS in %install?
Also, buildroot is deleted automatically nowadays. No need to keep the "#rm -rf $RPM_BUILD_ROOT" commented out, since %buildroot and $RPM_BUILD_ROOT should not be mixed anyway:

https://fedoraproject.org/wiki/Packaging:Guidelines#BuildRoot_tag

https://fedoraproject.org/wiki/Packaging:Guidelines#Using_.25.7Bbuildroot.7D_and_.25.7Boptflags.7D_vs_.24RPM_BUILD_ROOT_and_.24RPM_OPT_FLAGS


> install -pm755 %{buildroot}%{_datadir}/atom/libchromiumcontent.so %{buildroot}%{_libdir}
> install -pm755 %{buildroot}%{_datadir}/atom/libudev.so.0 %{buildroot}%{_libdir}
rm -Rf /tmp/atom-build

This is highly suspicious. Why are arch-specific libs installed into /usr/share/atom? How are they found and loaded at runtime? And why are they moved to %_libdir without a comment? At least the spec file ought to give a rationale here.


> %{_datadir}/applications/Atom.desktop

https://fedoraproject.org/wiki/Packaging:Guidelines#Desktop_files

If desktop-file-utils are used implicitly, please add a comment.


> %post
> 
> %preun
> 
> %postun

Delete unused scriptlet sections. They will cause you major pain, if you don't want any such scriptlets but include scripts by accident (e.g. by spec file comments in a false place below them).


> %clean
>#rm -rf $RPM_BUILD_ROOT

https://fedoraproject.org/wiki/Packaging:Guidelines#.25clean


> %files
> %defattr(-,root,root,-)

Notice that it's the default %defattr nowadays, and you didn't add it for the -libs package either, so better get rid of it:
https://fedoraproject.org/wiki/Packaging:Guidelines#File_Permissions


> %dir %{_datadir}/atom
> %{_datadir}/atom/*

Shorter:

  %{_datadir}/atom/

The trailing slash would not be needed, but makes it more explicit that it's a directory to be included, not a single file.

%dir only is helpful if you want to include the entry for a directory but specify individual files in it instead of the '*'-everything wildcard. Sort of:

  %files
  %dir %{_datadir}/somedir
  %{_datadir}/somedir/file1
  %{_datadir}/somedir/file2
  %{_datadir}/somedir/file3

  %files subpkg1
  %{_datadir}/somedir/file4
  %{_datadir}/somedir/file5
Comment 7 Paulo Fidalgo 2015-05-04 06:20:07 EDT
Any update on this, I will love to have the editor packaged on Fedora. Also atom provides an rpm, maybe the work can be used (just guessing due the lack of RPM packaging knowledge)
Comment 8 Michael Schwendt 2015-05-04 07:12:26 EDT
https://fedoraproject.org/wiki/Category:Package_Maintainers

 -> https://fedoraproject.org/wiki/Join_the_package_collection_maintainers
 -> https://fedoraproject.org/wiki/How_to_get_sponsored_into_the_packager_group

There are Packaging HOWTOs on that page, too. And in case there are questions, Fedora offers places where other packagers would answer.

All that would need to happen is for somebody to be willing to volunteer as the Fedora package maintainer for this software and show interest in RPM packaging and Fedora's packaging guidelines. And review process. Else not much will happen except for "unofficial" package builds getting published in random places such as Fedora Copr.
Comment 9 Oliver Haessler 2015-07-10 03:38:33 EDT
Is this review still active? I checked the spec from 
https://copr-be.cloud.fedoraproject.org/results/helber/atom/epel-7-x86_64/atom-1.0.1-1.fc22/atom-1.0.1-1.el7.centos.src.rpm

and i see that the changes Michael mentioned are not included (not even the small once like deleting unused snippets like %preun or %postun
Comment 10 Ryan Sawhill 2015-07-10 10:16:48 EDT
Also, it's worth noting that since https://github.com/atom/atom/releases/tag/v0.140.0 (October 27), the Atom team has been building their own rpms with every release.
Comment 11 Mohammed Safwat 2015-11-13 13:01:21 EST
I'd also like to see this package added to fedora repos. Version 1.2.0 has now been released https://github.com/atom/atom/releases/tag/v1.2.0.

Also as illustrated here https://github.com/atom/atom/blob/v1.2.0/docs/build-instructions/linux.md, the build instructions have been much simplified from what's included in the spec file in this review.

The license mentioned in the spec file is MIT, although I can't see this clear anywhere in the sources. The licensing terms here https://github.com/atom/atom/blob/v1.2.0/LICENSE.md are a little confusing as I can't clearly map to one of the good licenses approved by fedora packaging committee https://fedoraproject.org/wiki/Licensing:Main?rd=Licensing#Good_Licenses.

Is there anything I can do to reactivate this review? It's been a while since Helber was active in addressing the review findings.
Comment 12 Rex Dieter 2015-11-13 13:10:16 EST
Submitter of this request hasn't posted since Aug 2014, which is over a year ago.

I'm going to mark this as a dead review, please re-open if you (submitter) is still interested in this.
Comment 13 Mohammed Safwat 2015-11-15 09:43:47 EST
What if the original submitter is no longer interested and I'm willing to take over the packaging for atom? I'm already a fedora packager. Should I start afresh from a new spec file(and a new review ticket) or should I base my work on the one here(addressing the review remarks raised so far)?
Comment 14 Rex Dieter 2015-11-16 18:58:20 EST
Start a new review, ideally based partly on the work already done here
Comment 15 Milan Bouchet-Valat 2016-03-10 09:55:58 EST
Mohammed, are you still interested in taking up this work? I'd be willing to help package and review Atom.

FWIW, the license you pointed to is clearly MIT, so that shouldn't be an issue. Compare its text with https://opensource.org/licenses/MIT
Comment 16 Mohammed Safwat 2016-03-11 06:09:48 EST
I filed a ticket here https://bugzilla.redhat.com/show_bug.cgi?id=1286303 to request npm package upgrade since atom needs a version newer than the one provided by fedora. I've since waited for npm to be upgraded.

Just as I check today, I find that a new version 4.3.1 is slated for rawhide and fedora 24. I'm currently on fedora 23, so maybe I'll wait till fedora 24 is released before I set off to create an atom package.

Please note that based on Rex's comment above, I'm going to start a new ticket for atom review, not continue it here.
Comment 17 Helber Maciel Guerra 2016-03-11 07:03:06 EST
Hi, Mohammed Safwat.

I still update atom version on my copr (https://copr.fedorainfracloud.org/coprs/helber/atom/), and this is a rpm spec:
https://github.com/helber/fedora-specs/blob/master/atom/atom.spec
I hope this spec can help you.

On your issue https://bugzilla.redhat.com/show_bug.cgi?id=1286303 Zuzana Svetlikova, ask to use "npm install -g ". On my spec lines 63 to 69 i use npm updated on alternative directory. To use new i change PATH (line 69).

The alpha version of atom editor need newer version of nodejs. On near future you will need to ask nodejs maintainer to update, or use some type of alternatives. You can see here (https://github.com/helber/fedora-specs/issues/2) and here (https://github.com/FZUG/repo/issues/64). On this second one, he also want to be atom packager.

If you need a help, please ask me.
Comment 18 Milan Bouchet-Valat 2016-03-11 08:09:57 EST
(In reply to Mohammed Safwat from comment #16)
> I filed a ticket here https://bugzilla.redhat.com/show_bug.cgi?id=1286303 to
> request npm package upgrade since atom needs a version newer than the one
> provided by fedora. I've since waited for npm to be upgraded.
> 
> Just as I check today, I find that a new version 4.3.1 is slated for rawhide
> and fedora 24. I'm currently on fedora 23, so maybe I'll wait till fedora 24
> is released before I set off to create an atom package.
Note that you can easily build a package for F24/rawhide from F23 using Koji. See https://fedoraproject.org/wiki/Using_the_Koji_build_system#Scratch_Builds

I'm also on F23 and I do that all the time. I sometimes find it even easier than building packages on my machine, since everything is done automatically from a clean environment.

You may also be able to install manually the F24 packages for npm if you prefer.
Comment 19 Mohammed Safwat 2016-03-25 20:39:40 EDT
I tried scratch builds with koji and got stuck at errors during build like the ones found here http://koji.fedoraproject.org/koji/taskinfo?taskID=13462846.

The build steps for atom seem to contact github to grab some stuff related to npm and grunt(; I'm not an expert but that's what the logs are telling I assume). I guess koji build servers confine building packages inside a sandbox that wouldn't allow network access to external servers like github(and I don't blame this setup).

Now I'm left with installing npm package for F24 manually as Milan suggested or building from a private recent version of npm(created during build) as Helber suggested.
Comment 20 Milan Bouchet-Valat 2016-03-26 10:33:13 EDT
(In reply to Mohammed Safwat from comment #19)
> I tried scratch builds with koji and got stuck at errors during build like
> the ones found here
> http://koji.fedoraproject.org/koji/taskinfo?taskID=13462846.
> 
> The build steps for atom seem to contact github to grab some stuff related
> to npm and grunt(; I'm not an expert but that's what the logs are telling I
> assume). I guess koji build servers confine building packages inside a
> sandbox that wouldn't allow network access to external servers like
> github(and I don't blame this setup).
Indeed, Fedora packages must be built without network access, to ensure they can be reliably created only from the SRPM.

> Now I'm left with installing npm package for F24 manually as Milan suggested
> or building from a private recent version of npm(created during build) as
> Helber suggested.
While this is useful for development, this isn't a final solution, as the official package will have to build without Internet access.

Looking at the logs from [1], it seems to me you're going to have to package grunt-coffeelint, grunt-babel, grunt-lesslint, grunt-standard, grunt-cson, grunt-contrib-coffee, grunt-shell, grunt-download-electron, grunt-electron-installer and grunt-peg. While the list might seem scary, it should be a straightforward and quite repetitive task, and there are already a load of nodejs-grunt-* RPM packages in Fedora. See instructions at https://fedoraproject.org/wiki/Packaging:Node.js. If you file a new bug for these packages, you'll probably get help from people who have already packaged hundreds of RPMs like that.

1: https://copr-be.cloud.fedoraproject.org/results/helber/atom/fedora-rawhide-x86_64/00170302-atom/build.log.gz
Comment 21 sensor.wen 2016-04-04 18:24:38 EDT
Hi guys,

The package may not meet Fedora package guide. Because it need to download electron of precompiled when build atom. We need to split the package (atom, nodejs-atom-package-manager and electron).

It's really difficult. Electron is based on https://github.com/atom/libchromiumcontent. We need to hack electron, so that it uses the local library. In addition, the package review of Fedora is also very complicated.

https://fedoraproject.org/wiki/Chromium


Currently, I have done split atom and nodejs-atom-package-manager packages. The RPM build pass on my copr (https://copr.fedorainfracloud.org/coprs/mosquito/atom/), and Spec file in follows URL:

- https://github.com/FZUG/repo/blob/master/rpms/SPECS/atom/atom.spec
- https://github.com/FZUG/repo/blob/master/rpms/SPECS/atom/apm.spec
Comment 22 Mohammed Safwat 2016-04-09 18:10:59 EDT
I noticed the fact that electron was downloaded as an archive at some step during the build process. I was planning to package electron for this purpose so that atom may be made dependent on it.

I spent some time looking at the build scripts of atom. The problem isn't much about packaging grunt-* tasks as it's about packaging dependencies listed in the dependencies key here https://github.com/atom/atom/blob/v1.6.2/package.json. I don't know how deep this might go, as each npm package may have its own dependencies and so on. The alternative is to bundle these dependencies with atom package, which mightn't be very welcome by FPC.

Now coming to the concerns raised by sensor.wen, it seems even electron can't be packaged as there're still offending issues with libchromiumcontent(or chromium, whatever, I'm not an expert here so I'm just quoting sensor.wen's remarks). Don't know either about the necessity of separating atom and apm but given the apparently pending problems with electron, have we reached a dead end?
Comment 23 Milan Bouchet-Valat 2016-04-10 06:08:43 EDT
It looks like the Electron/Chromium issue is the most serious one. OTOH, the fact that Atom has a lot of dependencies on Node.js package isn't a big issue: there are already about 1000 such packages, so the cost of adding more of them (even if it turns out to be 50) isn't that high.
Comment 24 Milan Bouchet-Valat 2016-09-16 09:41:30 EDT
Chromium is now package in Fedora, so we should be able to make some progress if somebody is willing to try again.
Comment 25 jiri vanek 2016-10-16 06:37:12 EDT
Reseting to NEW so it appears in lists of opened review.
Comment 26 jeremy9856 2017-01-28 04:19:57 EST
Is there still something that block the package to be add in the repo ?
Comment 27 Rex Dieter 2017-01-28 12:22:48 EST
Only a able/willing reviewer, and probably wouldn't hurt to get a fresh .spec/srpm/comment from the submitter helber, who last commented here many months ago (2016-03-11)
Comment 28 Raphael Groner 2017-02-06 16:21:00 EST
What's the valuable state here? Are you still interested in this package?
Comment 29 Helber Maciel Guerra 2017-02-07 05:03:08 EST
Long time ago, the fedora FZUG group ask me to continue this job.

This os copr:
https://copr.fedorainfracloud.org/coprs/mosquito/atom/

Atom files:
https://github.com/1dot75cm/repo/tree/master/rpms/atom

The spec is:
https://github.com/1dot75cm/repo/blob/master/rpms/atom/atom.spec

The maintainer split this package on atom, electron, electron-legacy and nodejs-atom-package-manager. Based on my suggestion.

This package is very is not easy to create, and be accepted. As sensor.wen@gmail.com mention here: https://bugzilla.redhat.com/show_bug.cgi?id=1132661#c21
Comment 30 Alick Zhao 2017-02-07 12:47:20 EST
Hi sensor.wen (aka 1dot75cm, mosquito),

What's the current status of your atom packaging? Do you think it is ready for review?

I guess you need to turn the 'sed' lines into a separate patch.
Comment 31 sensor.wen 2017-02-09 11:59:05 EST
Hi guys,

The atom and nodejs-atom-package-manager packages only need little change for review. (create some patches)

Electron need some time to package. If it very well, i will submit a new package request.

Before submit the Atom review, I think we should review the Electron first.
Comment 32 sensor.wen 2017-02-09 13:08:15 EST
Really want to package these for Atom? Koji does not permit accessing the network. How to download these nodejs packages?

```
$ ll /usr/lib64/atom/node_modules/ | wc -l
441
```

The nodejs-atom-package-manager package has same problem. 
```
$ ll /usr/lib/node_modules/atom-package-manager/node_modules/ | wc -l
158
```
Comment 33 Alick Zhao 2017-02-09 13:12:43 EST
(In reply to sensor.wen from comment #32)
> Really want to package these for Atom? Koji does not permit accessing the
> network. How to download these nodejs packages?
> 
> ```
> $ ll /usr/lib64/atom/node_modules/ | wc -l
> 441
> ```
> 
> The nodejs-atom-package-manager package has same problem. 
> ```
> $ ll /usr/lib/node_modules/atom-package-manager/node_modules/ | wc -l
> 158
> ```

I think you need to package these node modules and specify them as builddeps.

(In reply to sensor.wen from comment #31)
> Hi guys,
> 
> The atom and nodejs-atom-package-manager packages only need little change
> for review. (create some patches)
> 
> Electron need some time to package. If it very well, i will submit a new
> package request.
> 
> Before submit the Atom review, I think we should review the Electron first.

Please open a new review request bug for electron and let it block this bug when you have a draft build for it.
Comment 35 Raphael Groner 2017-03-04 14:11:46 EST
Hi Dominik,
you can open a new package review request and close this one as a duplication. Your FAS seems to be inder, this user is currently not in the packager group. That means you first need to get sponsored as a packager.
https://fedoraproject.org/wiki/Join_the_package_collection_maintainers#Get_Sponsored

##
Now some general advice to your spec file:

- Where did you download the source tarball? You have to provide a valid URL or at least explain (by comment) how to create the tarball.
> Source: %{name}-%{version}.tar.xz
https://fedoraproject.org/wiki/Packaging:SourceURL#Referencing_Source
https://fedoraproject.org/wiki/Packaging:SourceURL#When_Upstream_uses_Prohibited_Code

- You can expect implicit dependencies of gcc-c++ or the general build environment and do not need to list them explicitly:
> BuildRequires: make
> BuildRequires: gcc
> BuildRequires: glibc-devel
> BuildRequires: rpmdevtools

- %description line is too long, insert a line break after 'core—a tool'
  to split into two lines.

- Please set all %global at the beginning of the file.

- Please use 'cp -p' to preserve timestamps.
https://fedoraproject.org/wiki/Packaging:Guidelines#Timestamps

- Please provide a link to the raw spec file to let fedora-review tool properly download:
https://gist.githubusercontent.com/I-n-d-e-r/fa7f3322e08df951b584336a886dea7e/raw/bbb5dffa6cff7f5e380a8b0f0ddc86835e7692e0/atom.spec
Comment 36 Raphael Groner 2017-03-29 21:04:29 EDT
No response since weeks. Closing here, please feel free to reopen if you still think there's an issue.
Comment 37 jeremy9856 2017-03-30 01:11:50 EDT
I really hope that Atom will be available into Fedora.
Thanks !
Comment 38 Raphael Groner 2017-03-30 01:44:40 EDT
(In reply to jeremy9856 from comment #37)
> I really hope that Atom will be available into Fedora.
> Thanks !

Copr has some builds but latest for Fedora 23 which is EOL. You could ask helber to provide more recent builds or use your own copr to build for current Fedora.
https://copr.fedorainfracloud.org/coprs/helber/atom/

Maybe also ask upstream for help as done already for other distributions.
https://github.com/atom/atom/issues/2956
https://discuss.atom.io/t/why-isnt-atom-in-any-official-repository/29294/2
Comment 39 jeremy9856 2017-03-30 07:10:37 EDT
I use the this copr repo "mosquito/atom" that provide up to date build for F25 but it would be great to have atom in the official repo.
Comment 40 Raphael Groner 2017-03-30 12:49:56 EDT
See also http://blog.atom.io/2014/11/05/linux-packages.html
Comment 41 Paulo Fidalgo 2017-03-31 03:54:35 EDT
More info about Atom is present on this wiki page: https://fedoraproject.org/wiki/Atom

Also don't use helber copr, use the mosquito one. I've been using it and so far so good!
Comment 42 Per Bothner 2017-04-14 19:26:33 EDT
I think it would make sense to split this, and start out by packaging Electron.  Electron is used not only by Atom, but also VSCode, and a number of other large and small application.  Two medium-sized projects that run on Electron are the Monaco text editor (part of VSCode), and DomTerm (see bug 142489).  (Neither of these two projects require Electron, but electron is a convenient way to run them as standalone applications.)

So an electron package would be useful in itself, in addition to being a useful stepping-stone to an atom package.
Comment 43 jeremy9856 2017-05-01 03:27:27 EDT
(In reply to Dominik Opyd from comment #34)
> Guys, I created pure RPM package for latest Atom and APM. Previously
> mentioned problems do not occur, everything works as it should. How I take
> over this review? Or maybe I should create new one?

Dominik are you still interested in packaging Atom ?
Comment 44 Mike Goodwin 2017-05-06 12:05:56 EDT
Packaging atom isn't even remotely a possibility until electron is able to be built on koji. 

It seems the gentoo guys figured out how to build it at least: https://gitweb.gentoo.org/repo/gentoo.git/tree/dev-util/electron/electron-1.3.13-r1.ebuild

This is a massive undertaking that will likely needs its own SIG/Community surrounding it and the current chromium builds. (poor tom) There are hundreds of electron based apps out there that are ripe for packaging, imho. My personal interest is for Rocket.Chat.Electron. None of this is going to see any fruition until their foundation (electron) is through review and able to be consistently maintained.

One of the biggest problems that I can tell is that the chromium/libchromiumcontent/electron instructions are based on pulling all sorts of precompiled nonsense from their entire ecosystem - something which I guess is to be expected from a chromium based project. This won't fly here, and as such it needs to be torn down a re-done to be able to be packaged with what's available to koji (and would probably have to be heavily based on the efforts of @spot in packaging chromium) - as it stands I couldn't even get electron to pass the bootstrap and/or build phase based on the instructions they provide (https://github.com/electron/electron/blob/master/docs/development/build-instructions-linux.md) and that includes allowing it to pull all of the bundled material. It's honestly suspect whether there are more than a handful of people out there right now that can actually build it, it seems.

The next hurdle after that is going to be in automating and packaging the (what im sure are hundreds) of node dependencies needed by atom, and after that, unbundling atom and getting it to use all the previously mentioned efforts properly. 

I highly doubt any one person will undertake these tasks in order to actually packaged this monstrosity in such a way that would actually pass review, unless we amass a significantly large community of people willing to work on it. 

I'm not holding my breath, though.
Comment 45 Dominik Opyd 2017-05-06 17:07:36 EDT
(In reply to jeremy9856 from comment #43)
> (In reply to Dominik Opyd from comment #34)
> > Guys, I created pure RPM package for latest Atom and APM. Previously
> > mentioned problems do not occur, everything works as it should. How I take
> > over this review? Or maybe I should create new one?
> 
> Dominik are you still interested in packaging Atom ?

Yes, I am :) I have little time now and I work. I will be able to take care of it in about 2 weeks.
Comment 46 Andrew Toskin 2017-05-07 19:58:56 EDT
(In reply to Mike Goodwin from comment #44)
> This is a massive undertaking that will likely needs its own SIG/Community
> surrounding it and the current chromium builds.

Good point. Maybe post about starting such a Special Interest Group on one of the mailing lists, or contacting someone in FESCO.

Note You need to log in before you can comment on or make changes to this bug.