It would be nice to have trendy and hip editor [0] in openSUSE. Currently however some nodejs dependencies are missing.

What needs to be done:

  • Package atom dependencies (mostly nodejs packages) - [1]
  • There is documentation on how to do so [2][3] using nodejs-packaging helper [4] but there are some limitations for packages with dependencies
  • Try using local-npm as local fake registry [5]
  • Current first attempt is at my home project [6], but i would like to push as much as possible to proper devel project [7]
  • Submit result to Factory (and potentially Backports [8][9] and Leap as well)
0. https://github.com/atom/atom
1. https://github.com/atom/atom/blob/master/package.json
2. https://en.opensuse.org/openSUSE:Packaging_nodejs
3. https://fedoraproject.org/wiki/Packaging:Node.js?rd=Node.js/Packagers
4. https://github.com/AdamMajer/nodejs-packaging
5. https://github.com/nolanlawson/local-npm
6. https://build.opensuse.org/project/show/homeadd-emojiatom
7. https://build.opensuse.org/project/show/develadd-emojinodejs
8. https://en.opensuse.org/Portal:Backports
9. https://en.opensuse.org/openSUSE:BackportsPackageSubmission_Process

Looking for mad skills in:

packaging npm

This project is part of:

Hack Week 15

Activity

  • 11 months ago: dasantiago left package Atom and its dependencies for openSUSE
  • almost 2 years ago: blarson liked package Atom and its dependencies for openSUSE
  • almost 2 years ago: diegoakechi liked package Atom and its dependencies for openSUSE
  • about 2 years ago: troy_topnik liked package Atom and its dependencies for openSUSE
  • about 2 years ago: farahschueller liked package Atom and its dependencies for openSUSE
  • Show History

    Comments

    • mkittler
      about 2 years ago by mkittler | Reply

      Atom and its dependencies are already packaged under Arch Linux so you can just convert their PKGBUILDs to rmp specs.

      • pluskalm
        about 2 years ago by pluskalm | Reply

        In Arch linux, only binary provided by upstream is repackaged, while all dependencies stay bundled.

    • lslezak
      about 2 years ago by lslezak | Reply

      And what's wrong with the official RPM? (https://atom.io/download/rpm) It works for me well in Leap 42.2...

      • pluskalm
        about 2 years ago by pluskalm | Reply

        Well there are several things wrong with official rpm, it bundles all of its dependecies in itself, plus we are interested in having Atom in distribution - having openSUSE users rely on binary provided by third party (even though its upstream project) does not seem like a right think to do to me.

    • MargueriteSu
      about 2 years ago by MargueriteSu | Reply

      Hi, I have been preparing/working on this for about two years. Two main things:

      A. We can't use the "one package per nodejs module" packaging method. (Some SUSE people invented or borrowed it to openSUSE in the beginning)

      Nodejs modules can have their own 'home' to place dependencies. That is, you can rely on a very very old version of something. You don't have to update it at all. Because you have your own home. You don't have to update it.

      This situation will result two different kinds of troubles:

      A.1 security issues. No need to further explain.

      A.2 muti-versions co-existed for the same module as different packages.

      I maintained develadd-emojinodejs for two+ years. this is heart-breaking. and fragmentation. Can you imagine to update 200+ packages in one night by hand? 4 times a month? Just no go.

      There's even no way to automate it.

      package.json can only list the dependencies of this module. no dependencies for a dependency.

      You can't shrinkwrap it. because a batch update will break other packages depend on one of the packages you update (multi-version issue). It is an endless loop as the packages in the repository are growing in amount.

      So you can only package one by one. Watch on build.opensuse.org to find out dependencies for one package (no way on your own machine, because you can't see dependency for dependency since you have only one source tarball), package dependencies, find dependencies for dependencies, package, and so on.

      Based on these facts. I decided to package nodejs module and all its dependencies in one package (bundle).

      That'll be too much easy to maintain and automate.

      I invented a "nodejs-packaging" toolkit in github.com/marguerite/nodejs-packaging, which is far more reasonable than the Fedora one. On your own machine, you can use my tool to create a .json file contains a dependency map. And download all the source tarballs needed, Autofill the specfile. Write changelog. Then submit.

      For security issues, I invented another tool to parse the .json my tool created and find the specific version of a dependency out among packages in the repository. Easy target, Easy fix.

      I have done this last year. But I found my tool is too bad in coding style...and less comments...so I can't even read some parts of it now.

      This year, I started it over again, by following Ruby coding style and writing nice comments. Also I wanted to split it into a few standard rubygems so we can maintain it in our ruby repository automatically.

      So I'd say your project now highly relies on my process of developing the tool...

      B. Atom relies on electron. Currently there's no native build of electron on any distribution.

      I started to package electron to make it build natively on OBS last year.

      I have finished "libchromiumcontent" package which is basically a rebuild of chromium :-(

      But I didn't finish the "electron" yet. Because its build script focus on building on your own machine instead of standard build virtual machine (it uses 'git' at build time), so I have to patch it, and separately package all its dependencies. BTW It is written in Python. Any help is welcome.

      Marguerite

    • dasantiago
      almost 2 years ago by dasantiago | Reply

      Lessons learned:

      • Not recommended/advised to split nodejs modules into packages. The nodejs modules need to be local, as it's the way npm will deal with the dependency versions. IF the packages are installed globally nodejs don't recognize them as libraries.

      • The current nodejs rpm macros aren't suitable for this as it changes the variable npm _ config _ prefix. This will cause the npm to stop knowing about required global nodejs packages already installed

      • Atom will download the electron binary, so we need to compile electron first.

      • To compile electron we need the ninja build system, which in turn will download all the required dependencies code and dependencies (it downloads more than 1GiB of files).

      Next hackweek activities:

      • Install a couchdb on the OBS so we can emulate the behaviour in a normal system with internet

    Similar Projects

    package mediagoblin by mstrigl

    From the mediagoblin.org website:

    "MediaGobl...


    Multimedia insane migration by scarabeus_iv

    Packman reduction

    Since w...


    "emerge" for rpm/SUSE by dmacvicar

    There are lot of packages that can't be hosted ...


    Inqlude, the Qt software archive by cschum

    During Hack Week 7 I worked on an archive of Qt...


    Compare & implement a simple way to startup an open SIS by bear454

    Washington state is a leader in Alternative Lea...