First draft of script and spec files

[Troy Dawson]

This is my first draft of a script, and corresponding spec file changes.
Feedback is welcome.

Bundling Script:
#!/bin/bash
PACKAGE="node-static"
VERSION="$(npm view ${PACKAGE} version)"
TMP_DIR=$(mktemp -d -t ci-XXXXXXXXXX)
mkdir ${TMP_DIR}
pushd ${TMP_DIR}
npm pack ${PACKAGE}
tar xfz *.tgz
cd package
npm install --no-optional --only=prod
# FIND SOMEWHERE TO PUT LICENSES
# FOR NOW JUST PRINT THEM OUT
find . -name "package.json" -exec jq .license {} ; | sort -u
mv node_modules/ node_modules_prod
npm install --no-optional --only=dev
mv node_modules/ node_modules_dev
tar cfz ../${PACKAGE}-${VERSION}-nm-prod.tgz node_modules_prod
tar cfz ../${PACKAGE}-${VERSION}-nm-dev.tgz node_modules_dev
cd ..
cp ${PACKAGE}-${VERSION}* $HOME/rpmbuild/SOURCES
popd
rm -rf ${TMP_DIR}

Spec File Changes:
...
License:  <license1> and <license2> and <license3>
...
Source1:       %{npm_name}-%{version}-nm-prod.tgz
Source2:       %{npm_name}-%{version}-nm-dev.tgz
...
%install
...
# Setup bundled node modules
tar xfz %{SOURCE1}
mkdir -p node_modules
pushd node_modules
ln -s ../node_modules_prod/* .
ln -s ../node_modules_prod/.bin .
popd
cp -pr node_modules node_modules_prod %{buildroot}%{nodejs_sitelib}/%{npm_name}
...
%check
%nodejs_symlink_deps --check
%if 0%{?enable_tests}
tar xfz %{SOURCE2}
pushd node_modules
ln -s ../node_modules_dev/* .
popd
pushd node_modules/.bin
ln -s ../../node_modules_dev/.bin/* .
popd
# Example test run using the binary in ./node_modules/.bin/
./node_modules/.bin/vows --spec --isolate
%endif
...

Known Issues:
- Hard coded package name, make that a variable.
- License - Tells you what they are, doesn't put them in nice format.
- Only for no-arch packages.  Doesn't deal with packages that need to
be compiled.
- Spec file stuff is a bit ugly.  Possibly write some macros once
things are finalized.

Notes:
- I used npm-install instead of yarn because npm because npm is in
RHEL, and when people think of nodejs modules, npm is usually what
they first thing ok.
- Although this has only been tested on one package, I believe it
should work on most no-arch nodejs packages.

Any changes and/or improvements that people think should be made?

Troy

[Tom Hughes]

On 03/09/2020 16:41, Troy Dawson wrote:
> Any changes and/or improvements that people think should be made?

Well macros for all that boilerplate in the spec is an
obvious one.

Also making the script fetch the actual version being packaged 
rather than the latest version would be good. Something like:

VERSION="$(rpmspec --srpm --queryformat=%{VERSION} -q nodejs-${PACKAGE}.spec)"

and then:

npm pack ${PACKAGE}@${VERSION}

Tom

[Troy Dawson]

On Thu, Sep 3, 2020 at 9:28 AM Tom Hughes  wrote:
> On 03/09/2020 16:41, Troy Dawson wrote:
> > Any changes and/or improvements that people think should be made?
>
> Well macros for all that boilerplate in the spec is an
> obvious one.
>
> Also making the script fetch the actual version being packaged
> rather than the latest version would be good. Something like:
>
> VERSION="$(rpmspec --srpm --queryformat=%{VERSION} -q nodejs-${PACKAGE}.spec)"
>
> and then:
>
> npm pack ${PACKAGE}@${VERSION}
>
> Tom

Good point.  I guess I had sorta hard coded both the name and the version.
So if they provide a version, use it, and if not, use the latest.

Troy

[Ben Rosser]

On Thu, Sep 3, 2020 at 1:04 PM Troy Dawson  wrote:
> On Thu, Sep 3, 2020 at 9:28 AM Tom Hughes  wrote:
> > On 03/09/2020 16:41, Troy Dawson wrote:
> > > Any changes and/or improvements that people think should be made?
> >
> > Well macros for all that boilerplate in the spec is an
> > obvious one.
> >
> > Also making the script fetch the actual version being packaged
> > rather than the latest version would be good. Something like:
> >
> > VERSION="$(rpmspec --srpm --queryformat=%{VERSION} -q nodejs-${PACKAGE}.spec)"
> >
> > and then:
> >
> > npm pack ${PACKAGE}@${VERSION}
> >
> > Tom
>
> Good point.  I guess I had sorta hard coded both the name and the version.
> So if they provide a version, use it, and if not, use the latest.

Hi Troy,

This looks pretty reasonable to me. (Sorry, I intended to try and work
on something like this myself over the summer but didn't end up having
time. Thanks for working on it!)

I'd been thinking the script would have one source archive per nodejs
module rather than a single source archive with all the bundled
dependencies, but on second thought that probably would be extremely
unwieldy, so perhaps bundling them together into a tarball is better.

What are your thoughts on deploying this? Node packages are going to
be broken in Fedora 33, but it's probably way too late to fix that
now, so perhaps there should be a Fedora 34 Change proposal?

Ben Rosser

[Troy Dawson]

On Thu, Sep 10, 2020 at 2:27 PM Ben Rosser  wrote:
> On Thu, Sep 3, 2020 at 1:04 PM Troy Dawson  wrote:
> > On Thu, Sep 3, 2020 at 9:28 AM Tom Hughes  wrote:
> > > On 03/09/2020 16:41, Troy Dawson wrote:
> > > > Any changes and/or improvements that people think should be made?
> > >
> > > Well macros for all that boilerplate in the spec is an
> > > obvious one.
> > >
> > > Also making the script fetch the actual version being packaged
> > > rather than the latest version would be good. Something like:
> > >
> > > VERSION="$(rpmspec --srpm --queryformat=%{VERSION} -q nodejs-${PACKAGE}.spec)"
> > >
> > > and then:
> > >
> > > npm pack ${PACKAGE}@${VERSION}
> > >
> > > Tom
> >
> > Good point.  I guess I had sorta hard coded both the name and the version.
> > So if they provide a version, use it, and if not, use the latest.
>
> Hi Troy,
>
> This looks pretty reasonable to me. (Sorry, I intended to try and work
> on something like this myself over the summer but didn't end up having
> time. Thanks for working on it!)
>
> I'd been thinking the script would have one source archive per nodejs
> module rather than a single source archive with all the bundled
> dependencies, but on second thought that probably would be extremely
> unwieldy, so perhaps bundling them together into a tarball is better.
>
> What are your thoughts on deploying this? Node packages are going to
> be broken in Fedora 33, but it's probably way too late to fix that
> now, so perhaps there should be a Fedora 34 Change proposal?
>
> Ben Rosser

I've never done a change proposal, so I'm not sure of everything it
would involve.
Do we say something to the effect of "All non-needed nodejs libraries
are to be removed, and those that are needed will bundle their
dependencies in this way?"

We would then have to define "needed" libraries.
I would think of these as the initial libraries other packages require.
An example would be nodejs-showdown.  R-shiny requires nodejs-showdown
to build and run.
So nodejs-showdown would be a needed nodejs-library.  But we could
bundle all of its runtime and testing dependencies, so it wouldn't
drag in any extra nodejs libraries.

If we are going along that route, I think saying something similar for
nodejs binaries would be appropriate.  Packages like coffee-script,
uglify-js, and other packages like those.
Perhaps not as strong as with libraries, something like
"Nodejs binaries should bundle their nodejs runtime and testing
dependencies whenever possible.  If it is not possible, then those
nodejs dependencies should be treated as needed nodejs libraries."

Troy

[Stephen Gallagher]

On Fri, Sep 18, 2020 at 11:33 AM Troy Dawson  wrote:
> On Thu, Sep 10, 2020 at 2:27 PM Ben Rosser  wrote:
> > On Thu, Sep 3, 2020 at 1:04 PM Troy Dawson  wrote:
> > > On Thu, Sep 3, 2020 at 9:28 AM Tom Hughes  wrote:
> > > > On 03/09/2020 16:41, Troy Dawson wrote:
> > > > > Any changes and/or improvements that people think should be made?
> > > >
> > > > Well macros for all that boilerplate in the spec is an
> > > > obvious one.
> > > >
> > > > Also making the script fetch the actual version being packaged
> > > > rather than the latest version would be good. Something like:
> > > >
> > > > VERSION="$(rpmspec --srpm --queryformat=%{VERSION} -q nodejs-${PACKAGE}.spec)"
> > > >
> > > > and then:
> > > >
> > > > npm pack ${PACKAGE}@${VERSION}
> > > >
> > > > Tom
> > >
> > > Good point.  I guess I had sorta hard coded both the name and the version.
> > > So if they provide a version, use it, and if not, use the latest.
> >
> > Hi Troy,
> >
> > This looks pretty reasonable to me. (Sorry, I intended to try and work
> > on something like this myself over the summer but didn't end up having
> > time. Thanks for working on it!)
> >
> > I'd been thinking the script would have one source archive per nodejs
> > module rather than a single source archive with all the bundled
> > dependencies, but on second thought that probably would be extremely
> > unwieldy, so perhaps bundling them together into a tarball is better.
> >
> > What are your thoughts on deploying this? Node packages are going to
> > be broken in Fedora 33, but it's probably way too late to fix that
> > now, so perhaps there should be a Fedora 34 Change proposal?
> >
> > Ben Rosser
>
> I've never done a change proposal, so I'm not sure of everything it
> would involve.
> Do we say something to the effect of "All non-needed nodejs libraries
> are to be removed, and those that are needed will bundle their
> dependencies in this way?"
>
> We would then have to define "needed" libraries.
> I would think of these as the initial libraries other packages require.
> An example would be nodejs-showdown.  R-shiny requires nodejs-showdown
> to build and run.
> So nodejs-showdown would be a needed nodejs-library.  But we could
> bundle all of its runtime and testing dependencies, so it wouldn't
> drag in any extra nodejs libraries.
>
> If we are going along that route, I think saying something similar for
> nodejs binaries would be appropriate.  Packages like coffee-script,
> uglify-js, and other packages like those.
> Perhaps not as strong as with libraries, something like
> "Nodejs binaries should bundle their nodejs runtime and testing
> dependencies whenever possible.  If it is not possible, then those
> nodejs dependencies should be treated as needed nodejs libraries."

Frankly, I think we should probably get out of the business of
shipping library NPMs entirely. Upstream's stance on global vs. local
NPM installations is this [1]:

"""
Just like how global variables are kind of gross, but also necessary
in some cases, global packages are important, but best avoided if not
needed.

In general, the rule of thumb is:

* If you’re installing something that you want to use in your program,
using require('whatever'), then install it locally, at the root of
your project.
* If you’re installing something that you want to use in your shell,
on the command line or something, install it globally, so that its
binaries end up in your PATH environment variable.
"""

So, as a shorthand, I think Fedora should only package:

1) The interpreter, development headers/libraries, and the assorted
tools to manage project-level installations (NPM, yarn, etc.).
2) Packages that provide binaries that users would want to use in their shell.

I'm not sure when bundling their dependencies would be impossible. Can
you provide an example? The whole ecosystem is designed around
bundling as the preferred approach.

[1] https://nodejs.org/en/blog/npm/npm-1-0-global-vs-local-installation/

[Troy Dawson]

On Fri, Sep 18, 2020 at 8:47 AM Stephen Gallagher  wrote:
> On Fri, Sep 18, 2020 at 11:33 AM Troy Dawson  wrote:
> > On Thu, Sep 10, 2020 at 2:27 PM Ben Rosser  wrote:
> > > On Thu, Sep 3, 2020 at 1:04 PM Troy Dawson  wrote:
> > > > On Thu, Sep 3, 2020 at 9:28 AM Tom Hughes  wrote:
> > > > > On 03/09/2020 16:41, Troy Dawson wrote:
> > > > > > Any changes and/or improvements that people think should be made?
> > > > >
> > > > > Well macros for all that boilerplate in the spec is an
> > > > > obvious one.
> > > > >
> > > > > Also making the script fetch the actual version being packaged
> > > > > rather than the latest version would be good. Something like:
> > > > >
> > > > > VERSION="$(rpmspec --srpm --queryformat=%{VERSION} -q nodejs-${PACKAGE}.spec)"
> > > > >
> > > > > and then:
> > > > >
> > > > > npm pack ${PACKAGE}@${VERSION}
> > > > >
> > > > > Tom
> > > >
> > > > Good point.  I guess I had sorta hard coded both the name and the version.
> > > > So if they provide a version, use it, and if not, use the latest.
> > >
> > > Hi Troy,
> > >
> > > This looks pretty reasonable to me. (Sorry, I intended to try and work
> > > on something like this myself over the summer but didn't end up having
> > > time. Thanks for working on it!)
> > >
> > > I'd been thinking the script would have one source archive per nodejs
> > > module rather than a single source archive with all the bundled
> > > dependencies, but on second thought that probably would be extremely
> > > unwieldy, so perhaps bundling them together into a tarball is better.
> > >
> > > What are your thoughts on deploying this? Node packages are going to
> > > be broken in Fedora 33, but it's probably way too late to fix that
> > > now, so perhaps there should be a Fedora 34 Change proposal?
> > >
> > > Ben Rosser
> >
> > I've never done a change proposal, so I'm not sure of everything it
> > would involve.
> > Do we say something to the effect of "All non-needed nodejs libraries
> > are to be removed, and those that are needed will bundle their
> > dependencies in this way?"
> >
> > We would then have to define "needed" libraries.
> > I would think of these as the initial libraries other packages require.
> > An example would be nodejs-showdown.  R-shiny requires nodejs-showdown
> > to build and run.
> > So nodejs-showdown would be a needed nodejs-library.  But we could
> > bundle all of its runtime and testing dependencies, so it wouldn't
> > drag in any extra nodejs libraries.
> >
> > If we are going along that route, I think saying something similar for
> > nodejs binaries would be appropriate.  Packages like coffee-script,
> > uglify-js, and other packages like those.
> > Perhaps not as strong as with libraries, something like
> > "Nodejs binaries should bundle their nodejs runtime and testing
> > dependencies whenever possible.  If it is not possible, then those
> > nodejs dependencies should be treated as needed nodejs libraries."
>
> Frankly, I think we should probably get out of the business of
> shipping library NPMs entirely. Upstream's stance on global vs. local
> NPM installations is this [1]:
>
> """
> Just like how global variables are kind of gross, but also necessary
> in some cases, global packages are important, but best avoided if not
> needed.
>
> In general, the rule of thumb is:
> If you’re installing something that you want to use in your program,
>
> using require('whatever'), then install it locally, at the root of
> your project.
> If you’re installing something that you want to use in your shell,
>
> on the command line or something, install it globally, so that its
> binaries end up in your PATH environment variable.
> """
>
> So, as a shorthand, I think Fedora should only package:
> The interpreter, development headers/libraries, and the assorted
>
> tools to manage project-level installations (NPM, yarn, etc.).
> 2) Packages that provide binaries that users would want to use in their shell.
>
> I'm not sure when bundling their dependencies would be impossible. Can
> you provide an example? The whole ecosystem is designed around
> bundling as the preferred approach.
>
> [1] https://nodejs.org/en/blog/npm/npm-1-0-global-vs-local-installation/

I can't provide an example of when bundling would be impossible.  I
just assumed there would be one.
Part of me thinks this will be alot of work, and another part of me
thinks it will be less work than what I was proposing above.

I like your proposal over mine.  It's more clear, and clean.  And
after the initial set of work, the packaging workload drops.

Does anyone have any major objections before I look at how to do a
Fedora change proposal?

Troy

[Ben Rosser]

On Fri, Sep 18, 2020 at 12:56 PM Troy Dawson  wrote:
> On Fri, Sep 18, 2020 at 8:47 AM Stephen Gallagher  wrote:
> > On Fri, Sep 18, 2020 at 11:33 AM Troy Dawson  wrote:
> > > On Thu, Sep 10, 2020 at 2:27 PM Ben Rosser  wrote:
> > > > On Thu, Sep 3, 2020 at 1:04 PM Troy Dawson  wrote:
> > > > > On Thu, Sep 3, 2020 at 9:28 AM Tom Hughes  wrote:
> > > > > > On 03/09/2020 16:41, Troy Dawson wrote:
> > > > > >
> > > > > > > Any changes and/or improvements that people think should be made?
> > > > > >
> > > > > > Well macros for all that boilerplate in the spec is an
> > > > > > obvious one.
> > > > > >
> > > > > > Also making the script fetch the actual version being packaged
> > > > > > rather than the latest version would be good. Something like:
> > > > > >
> > > > > > VERSION="$(rpmspec --srpm --queryformat=%{VERSION} -q nodejs-${PACKAGE}.spec)"
> > > > > >
> > > > > > and then:
> > > > > >
> > > > > > npm pack ${PACKAGE}@${VERSION}
> > > > > >
> > > > > > Tom
> > > > >
> > > > > Good point.  I guess I had sorta hard coded both the name and the version.
> > > > > So if they provide a version, use it, and if not, use the latest.
> > > >
> > > > Hi Troy,
> > > >
> > > > This looks pretty reasonable to me. (Sorry, I intended to try and work
> > > > on something like this myself over the summer but didn't end up having
> > > > time. Thanks for working on it!)
> > > >
> > > > I'd been thinking the script would have one source archive per nodejs
> > > > module rather than a single source archive with all the bundled
> > > > dependencies, but on second thought that probably would be extremely
> > > > unwieldy, so perhaps bundling them together into a tarball is better.
> > > >
> > > > What are your thoughts on deploying this? Node packages are going to
> > > > be broken in Fedora 33, but it's probably way too late to fix that
> > > > now, so perhaps there should be a Fedora 34 Change proposal?
> > > >
> > > > Ben Rosser
> > >
> > > I've never done a change proposal, so I'm not sure of everything it
> > > would involve.
> > > Do we say something to the effect of "All non-needed nodejs libraries
> > > are to be removed, and those that are needed will bundle their
> > > dependencies in this way?"
> > >
> > > We would then have to define "needed" libraries.
> > > I would think of these as the initial libraries other packages require.
> > > An example would be nodejs-showdown.  R-shiny requires nodejs-showdown
> > > to build and run.
> > > So nodejs-showdown would be a needed nodejs-library.  But we could
> > > bundle all of its runtime and testing dependencies, so it wouldn't
> > > drag in any extra nodejs libraries.
> > >
> > > If we are going along that route, I think saying something similar for
> > > nodejs binaries would be appropriate.  Packages like coffee-script,
> > > uglify-js, and other packages like those.
> > > Perhaps not as strong as with libraries, something like
> > > "Nodejs binaries should bundle their nodejs runtime and testing
> > > dependencies whenever possible.  If it is not possible, then those
> > > nodejs dependencies should be treated as needed nodejs libraries."
> >
> > Frankly, I think we should probably get out of the business of
> > shipping library NPMs entirely. Upstream's stance on global vs. local
> > NPM installations is this [1]:
> >
> > """
> > Just like how global variables are kind of gross, but also necessary
> > in some cases, global packages are important, but best avoided if not
> > needed.
> >
> > In general, the rule of thumb is:
> > If you’re installing something that you want to use in your program,
> >
> > using require('whatever'), then install it locally, at the root of
> > your project.
> > If you’re installing something that you want to use in your shell,
> >
> > on the command line or something, install it globally, so that its
> > binaries end up in your PATH environment variable.
> > """
> >
> > So, as a shorthand, I think Fedora should only package:
> > The interpreter, development headers/libraries, and the assorted
> >
> > tools to manage project-level installations (NPM, yarn, etc.).
> > 2) Packages that provide binaries that users would want to use in their shell.
> >
> > I'm not sure when bundling their dependencies would be impossible. Can
> > you provide an example? The whole ecosystem is designed around
> > bundling as the preferred approach.
> >
> > [1] https://nodejs.org/en/blog/npm/npm-1-0-global-vs-local-installation/
>
> I can't provide an example of when bundling would be impossible.  I
> just assumed there would be one.
> Part of me thinks this will be alot of work, and another part of me
> thinks it will be less work than what I was proposing above.
>
> I like your proposal over mine.  It's more clear, and clean.  And
> after the initial set of work, the packaging workload drops.
>
> Does anyone have any major objections before I look at how to do a
> Fedora change proposal?
>
> Troy

At least for the short term, I'd suggest adding (3): compiled/binary
nodejs modules; there aren't very many of these in the ecosystem
anyway, as I understand it (there certainly aren't very many in
Fedora) so I don't think it would be too much work to package them
separately.

Otherwise, this sounds good to me!

Ben Rosser

[Stephen Gallagher]

On Fri, Sep 18, 2020 at 1:07 PM Ben Rosser  wrote:
> On Fri, Sep 18, 2020 at 12:56 PM Troy Dawson  wrote:
> > On Fri, Sep 18, 2020 at 8:47 AM Stephen Gallagher  wrote:

...
> > > Frankly, I think we should probably get out of the business of
> > > shipping library NPMs entirely. Upstream's stance on global vs. local
> > > NPM installations is this [1]:
> > >
> > > """
> > > Just like how global variables are kind of gross, but also necessary
> > > in some cases, global packages are important, but best avoided if not
> > > needed.
> > >
> > > In general, the rule of thumb is:
> > > If you’re installing something that you want to use in your program,
> > >
> > > using require('whatever'), then install it locally, at the root of
> > > your project.
> > > If you’re installing something that you want to use in your shell,
> > >
> > > on the command line or something, install it globally, so that its
> > > binaries end up in your PATH environment variable.
> > > """
> > >
> > > So, as a shorthand, I think Fedora should only package:
> > > The interpreter, development headers/libraries, and the assorted
> > >
> > > tools to manage project-level installations (NPM, yarn, etc.).
> > > 2) Packages that provide binaries that users would want to use in their shell.
> > >
> > > I'm not sure when bundling their dependencies would be impossible. Can
> > > you provide an example? The whole ecosystem is designed around
> > > bundling as the preferred approach.
> > >
> > > [1] https://nodejs.org/en/blog/npm/npm-1-0-global-vs-local-installation/
> >
> > I can't provide an example of when bundling would be impossible.  I
> > just assumed there would be one.
> > Part of me thinks this will be alot of work, and another part of me
> > thinks it will be less work than what I was proposing above.
> >
> > I like your proposal over mine.  It's more clear, and clean.  And
> > after the initial set of work, the packaging workload drops.
> >
> > Does anyone have any major objections before I look at how to do a
> > Fedora change proposal?
> >
> > Troy
>
> At least for the short term, I'd suggest adding (3): compiled/binary
> nodejs modules; there aren't very many of these in the ecosystem
> anyway, as I understand it (there certainly aren't very many in
> Fedora) so I don't think it would be too much work to package them
> separately.
>
> Otherwise, this sounds good to me!

Sounds like a reasonable approach. +1

[Troy Dawson]

Here is almost a first draft of the Change Proposal.
https://fedoraproject.org/wiki/Changes/NodejsLibrariesBundleByDefault

I currently have two questions
1 - Name ... I'm having a hard time with the name.  I'm currently at
"Stop Shipping Individual Nodejs Library Packages" but that doesn't
seem right.
2 - Updates.  Do we have some package with a giant list of obsoletes?
If so, what package?

On Fri, Sep 18, 2020 at 10:08 AM Stephen Gallagher  wrote:
> On Fri, Sep 18, 2020 at 1:07 PM Ben Rosser  wrote:
> > On Fri, Sep 18, 2020 at 12:56 PM Troy Dawson  wrote:
> > > On Fri, Sep 18, 2020 at 8:47 AM Stephen Gallagher  wrote:
>
> ...
> > > > Frankly, I think we should probably get out of the business of
> > > > shipping library NPMs entirely. Upstream's stance on global vs. local
> > > > NPM installations is this [1]:
> > > >
> > > > """
> > > > Just like how global variables are kind of gross, but also necessary
> > > > in some cases, global packages are important, but best avoided if not
> > > > needed.
> > > >
> > > > In general, the rule of thumb is:
> > > > If you’re installing something that you want to use in your program,
> > > >
> > > > using require('whatever'), then install it locally, at the root of
> > > > your project.
> > > > If you’re installing something that you want to use in your shell,
> > > >
> > > > on the command line or something, install it globally, so that its
> > > > binaries end up in your PATH environment variable.
> > > > """
> > > >
> > > > So, as a shorthand, I think Fedora should only package:
> > > > The interpreter, development headers/libraries, and the assorted
> > > >
> > > > tools to manage project-level installations (NPM, yarn, etc.).
> > > > 2) Packages that provide binaries that users would want to use in their shell.
> > > >
> > > > I'm not sure when bundling their dependencies would be impossible. Can
> > > > you provide an example? The whole ecosystem is designed around
> > > > bundling as the preferred approach.
> > > >
> > > > [1] https://nodejs.org/en/blog/npm/npm-1-0-global-vs-local-installation/
> > >
> > > I can't provide an example of when bundling would be impossible.  I
> > > just assumed there would be one.
> > > Part of me thinks this will be alot of work, and another part of me
> > > thinks it will be less work than what I was proposing above.
> > >
> > > I like your proposal over mine.  It's more clear, and clean.  And
> > > after the initial set of work, the packaging workload drops.
> > >
> > > Does anyone have any major objections before I look at how to do a
> > > Fedora change proposal?
> > >
> > > Troy
> >
> > At least for the short term, I'd suggest adding (3): compiled/binary
> > nodejs modules; there aren't very many of these in the ecosystem
> > anyway, as I understand it (there certainly aren't very many in
> > Fedora) so I don't think it would be too much work to package them
> > separately.
> >
> > Otherwise, this sounds good to me!
>
> Sounds like a reasonable approach. +1

[Neal Gompa]

On Wed, Sep 23, 2020 at 6:02 PM Troy Dawson  wrote:
> Here is almost a first draft of the Change Proposal.
> https://fedoraproject.org/wiki/Changes/NodejsLibrariesBundleByDefault
>
> I currently have two questions
> 1 - Name ... I'm having a hard time with the name.  I'm currently at
> "Stop Shipping Individual Nodejs Library Packages" but that doesn't
> seem right.

"Give up on packaging nodejs libraries"?
> 2 - Updates.  Do we have some package with a giant list of obsoletes?
> If so, what package?

We have fedora-obsolete-packages:
https://src.fedoraproject.org/rpms/fedora-obsolete-packages

[Troy Dawson]

On Wed, Sep 23, 2020 at 3:05 PM Neal Gompa  wrote:
> On Wed, Sep 23, 2020 at 6:02 PM Troy Dawson  wrote:
> > Here is almost a first draft of the Change Proposal.
> > https://fedoraproject.org/wiki/Changes/NodejsLibrariesBundleByDefault
> >
> > I currently have two questions
> > 1 - Name ... I'm having a hard time with the name.  I'm currently at
> > "Stop Shipping Individual Nodejs Library Packages" but that doesn't
> > seem right.
>
> "Give up on packaging nodejs libraries"?

Well, ya, if we're going to be honest, that is the best title. :)
> > 2 - Updates.  Do we have some package with a giant list of obsoletes?
> > If so, what package?
>
> We have fedora-obsolete-packages:
> https://src.fedoraproject.org/rpms/fedora-obsolete-packages

Cool.  I didn't know we had that.

[Neal Gompa]

On Wed, Sep 23, 2020 at 6:10 PM Troy Dawson  wrote:
> On Wed, Sep 23, 2020 at 3:05 PM Neal Gompa  wrote:
> > On Wed, Sep 23, 2020 at 6:02 PM Troy Dawson  wrote:
> > > Here is almost a first draft of the Change Proposal.
> > > https://fedoraproject.org/wiki/Changes/NodejsLibrariesBundleByDefault
> > >
> > > I currently have two questions
> > > 1 - Name ... I'm having a hard time with the name.  I'm currently at
> > > "Stop Shipping Individual Nodejs Library Packages" but that doesn't
> > > seem right.
> >
> > "Give up on packaging nodejs libraries"?
>
> Well, ya, if we're going to be honest, that is the best title. :)

The only bit I don't really know about with this proposal so far is
how to deal with license auditing. Our license tags are supposed to
reflect the licenses of all the different projects being shipped, and
we don't have good tools for that yet...

There's some in-progress work for rust2rpm[1], but we don't have
anything *really* to handle this well.

[1]: https://pagure.io/fedora-rust/rust2rpm/pull-request/105
> > > 2 - Updates.  Do we have some package with a giant list of obsoletes?
> > > If so, what package?
> >
> > We have fedora-obsolete-packages:
> > https://src.fedoraproject.org/rpms/fedora-obsolete-packages
>
> Cool.  I didn't know we had that.

It's been a few years, but I always remember it because I suggested it
to tibbs years ago. :)

[Stephen Gallagher]

On Wed, Sep 23, 2020 at 6:15 PM Neal Gompa  wrote:
> On Wed, Sep 23, 2020 at 6:10 PM Troy Dawson  wrote:
> >
> > On Wed, Sep 23, 2020 at 3:05 PM Neal Gompa  wrote:
> > >
> > > On Wed, Sep 23, 2020 at 6:02 PM Troy Dawson
>
> wrote:
> > > >
> > > > Here is almost a first draft of the Change Proposal.
> > > >
>
> https://fedoraproject.org/wiki/Changes/NodejsLibrariesBundleByDefault
> > > >
> > > > I currently have two questions
> > > > 1 - Name ... I'm having a hard time with the name.  I'm currently at
> > > > "Stop Shipping Individual Nodejs Library Packages" but that doesn't
> > > > seem right.
> > >
> > > "Give up on packaging nodejs libraries"?
> > >
> >
> > Well, ya, if we're going to be honest, that is the best title. :)
> >
>
> The only bit I don't really know about with this proposal so far is
>
> how to deal with license auditing. Our license tags are supposed to
>
> reflect the licenses of all the different projects being shipped, and
>
> we don't have good tools for that yet...
>
> There's some in-progress work for rust2rpm[1], but we don't have
>
> anything *really* to handle this well.

Node’s package.json contains the license, so we should be able to just
extract that recursively.
> > > > 2 - Updates.  Do we have some package with a giant list of obsoletes?
> > > > If so, what package?
> > > >
> > >
> > > We have fedora-obsolete-packages:
> > > https://src.fedoraproject.org/rpms/fedora-obsolete-packages
> > >
> > >
> >
> > Cool.  I didn't know we had that.
>
> It's been a few years, but I always remember it because I suggested it
>
> to tibbs years ago. :)
>
> --
>
> 真実はいつも一つ！/ Always, there's only one truth!

[Jared K. Smith]

On Wed, Sep 23, 2020 at 7:44 PM Stephen Gallagher 
wrote:
> Node’s package.json contains the license, so we should be able to just
> extract that recursively.

In theory, yes.  In practice, some packages completely leave it out, some
packages put it under "license" and some under "licenses", and many
packages don't bother to include the license text with the code.  I've
filed dozens of tickets with upstream NodeJS projects to improve these,
most of which have been ignored for years.  I've come to the unfortunate
conclusion that the NodeJS community in general can't be bothered with
license details.

-Jared

[Stephen Gallagher]

On Thu, Sep 24, 2020 at 7:52 AM Jared K. Smith  wrote:
> On Wed, Sep 23, 2020 at 7:44 PM Stephen Gallagher  wrote:
> > Node’s package.json contains the license, so we should be able to just extract that recursively.
>
> In theory, yes.  In practice, some packages completely leave it out, some packages put it under "license" and some under "licenses", and many packages don't bother to include the license text with the code.  I've filed dozens of tickets with upstream NodeJS projects to improve these, most of which have been ignored for years.  I've come to the unfortunate conclusion that the NodeJS community in general can't be bothered with license details.

I have spoken to a lawyer about this in the past. We are allowed to
make a "best reasonable effort" here. As long as we capture all of the
known licenses and we are responsive and immediately take action if
someone comes with a challenge, we should be fine.