Comments

• 

  almost 8 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.

  • 

    almost 8 years ago by pluskalm | Reply

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

  ×
  Edit Comment 2198
  # A First Level Header
  ## A Second Level Header
  
  Use one asterisk to *emphasize*
  
  Use two asterisks for **strong emphasis**
  
  - Use hyphens
  - for unordereed
  - lists
  
  This is an [link to example.com](http://example.com/)
  
  This is an image ![an openSUSE geeko icon](https://en.opensuse.org/images/d/d0/Icon-distribution.png)
  
  This is a user link @hans
  
  This is a project link hw#some-cool-title
  
  More Complex Markdown Help
  Formatting Help
  • Edit
  • Preview
  In Arch linux, only binary provided by upstream is repackaged, while all dependencies stay bundled.
   
  ×
  Reply to pluskalm
  In Arch linux, only binary provided by upstream is repackaged, while all dependencies stay bundled.
  ---
  # A First Level Header
  ## A Second Level Header
  
  Use one asterisk to *emphasize*
  
  Use two asterisks for **strong emphasis**
  
  - Use hyphens
  - for unordereed
  - lists
  
  This is an [link to example.com](http://example.com/)
  
  This is an image ![an openSUSE geeko icon](https://en.opensuse.org/images/d/d0/Icon-distribution.png)
  
  This is a user link @hans
  
  This is a project link hw#some-cool-title
  
  More Complex Markdown Help
  Formatting Help
  • Edit
  • Preview
   
×
Edit Comment 2182
# A First Level Header
## A Second Level Header

Use one asterisk to *emphasize*

Use two asterisks for **strong emphasis**

- Use hyphens
- for unordereed
- lists

This is an [link to example.com](http://example.com/)

This is an image ![an openSUSE geeko icon](https://en.opensuse.org/images/d/d0/Icon-distribution.png)

This is a user link @hans

This is a project link hw#some-cool-title
More Complex Markdown Help
Formatting Help
• Edit
• Preview
Atom and its dependencies are already packaged under Arch Linux so you can just convert their PKGBUILDs to rmp specs.
 
×
Reply to mkittler
Atom and its dependencies are already packaged under Arch Linux so you can just convert their PKGBUILDs to rmp specs.
---
# A First Level Header
## A Second Level Header

Use one asterisk to *emphasize*

Use two asterisks for **strong emphasis**

- Use hyphens
- for unordereed
- lists

This is an [link to example.com](http://example.com/)

This is an image ![an openSUSE geeko icon](https://en.opensuse.org/images/d/d0/Icon-distribution.png)

This is a user link @hans

This is a project link hw#some-cool-title
More Complex Markdown Help
Formatting Help
• Edit
• Preview
 
• 

  almost 8 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...

  • 

    almost 8 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.

  ×
  Edit Comment 2256
  # A First Level Header
  ## A Second Level Header
  
  Use one asterisk to *emphasize*
  
  Use two asterisks for **strong emphasis**
  
  - Use hyphens
  - for unordereed
  - lists
  
  This is an [link to example.com](http://example.com/)
  
  This is an image ![an openSUSE geeko icon](https://en.opensuse.org/images/d/d0/Icon-distribution.png)
  
  This is a user link @hans
  
  This is a project link hw#some-cool-title
  
  More Complex Markdown Help
  Formatting Help
  • Edit
  • Preview
  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.
   
  ×
  Reply to pluskalm
  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.
  ---
  # A First Level Header
  ## A Second Level Header
  
  Use one asterisk to *emphasize*
  
  Use two asterisks for **strong emphasis**
  
  - Use hyphens
  - for unordereed
  - lists
  
  This is an [link to example.com](http://example.com/)
  
  This is an image ![an openSUSE geeko icon](https://en.opensuse.org/images/d/d0/Icon-distribution.png)
  
  This is a user link @hans
  
  This is a project link hw#some-cool-title
  
  More Complex Markdown Help
  Formatting Help
  • Edit
  • Preview
   
×
Edit Comment 2226
# A First Level Header
## A Second Level Header

Use one asterisk to *emphasize*

Use two asterisks for **strong emphasis**

- Use hyphens
- for unordereed
- lists

This is an [link to example.com](http://example.com/)

This is an image ![an openSUSE geeko icon](https://en.opensuse.org/images/d/d0/Icon-distribution.png)

This is a user link @hans

This is a project link hw#some-cool-title
More Complex Markdown Help
Formatting Help
• Edit
• Preview
And what's wrong with the official RPM? (https://atom.io/download/rpm) It works for me well in Leap 42.2...
 
×
Reply to lslezak
And what's wrong with the official RPM? (https://atom.io/download/rpm) It works for me well in Leap 42.2...
---
# A First Level Header
## A Second Level Header

Use one asterisk to *emphasize*

Use two asterisks for **strong emphasis**

- Use hyphens
- for unordereed
- lists

This is an [link to example.com](http://example.com/)

This is an image ![an openSUSE geeko icon](https://en.opensuse.org/images/d/d0/Icon-distribution.png)

This is a user link @hans

This is a project link hw#some-cool-title
More Complex Markdown Help
Formatting Help
• Edit
• Preview
 
• 

  almost 8 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 devel:languages:nodejs 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

×
Edit Comment 2252
# A First Level Header
## A Second Level Header

Use one asterisk to *emphasize*

Use two asterisks for **strong emphasis**

- Use hyphens
- for unordereed
- lists

This is an [link to example.com](http://example.com/)

This is an image ![an openSUSE geeko icon](https://en.opensuse.org/images/d/d0/Icon-distribution.png)

This is a user link @hans

This is a project link hw#some-cool-title
More Complex Markdown Help
Formatting Help
• Edit
• Preview
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 devel:languages:nodejs 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
 
×
Reply to MargueriteSu
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 devel:languages:nodejs 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
---
# A First Level Header
## A Second Level Header

Use one asterisk to *emphasize*

Use two asterisks for **strong emphasis**

- Use hyphens
- for unordereed
- lists

This is an [link to example.com](http://example.com/)

This is an image ![an openSUSE geeko icon](https://en.opensuse.org/images/d/d0/Icon-distribution.png)

This is a user link @hans

This is a project link hw#some-cool-title
More Complex Markdown Help
Formatting Help
• Edit
• Preview
 
• 

  almost 8 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

×
Edit Comment 2556
# A First Level Header
## A Second Level Header

Use one asterisk to *emphasize*

Use two asterisks for **strong emphasis**

- Use hyphens
- for unordereed
- lists

This is an [link to example.com](http://example.com/)

This is an image ![an openSUSE geeko icon](https://en.opensuse.org/images/d/d0/Icon-distribution.png)

This is a user link @hans

This is a project link hw#some-cool-title
More Complex Markdown Help
Formatting Help
• Edit
• Preview
#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
 
×
Reply to dasantiago
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
---
# A First Level Header
## A Second Level Header

Use one asterisk to *emphasize*

Use two asterisks for **strong emphasis**

- Use hyphens
- for unordereed
- lists

This is an [link to example.com](http://example.com/)

This is an image ![an openSUSE geeko icon](https://en.opensuse.org/images/d/d0/Icon-distribution.png)

This is a user link @hans

This is a project link hw#some-cool-title
More Complex Markdown Help
Formatting Help
• Edit
• Preview