Hey guys,
Long time lurker, who wants to try and get more involved with Stephen's
shifting responsibilities. Is there a "getting started" or "hey new guy
don't E-mail the mailing list" approach to contributing to this? I've
heard Stephen refer to a COPR every now and then -- I'm aware of the COPR
at [1] which I forked into my own COPR, and then also the wiki [2] with
basic information on actually using Node.JS in Fedora. The packaging
Node.JS page [3] looks severely outdated, since we are now no longer
attempting to RPM package each individual NPM dependency and instead using
that built in process? (That was a question)
The other part I'm confused on is that the COPR shows the build was
triggered by a SRPM that was uploaded [4], but then also refers to a git
repository at [5]
I wanted to "cut my teeth" on trying to configure the COPR to do a Fedora
23 build, since I'm still on Fedora 23. How would I go about doing that?
As I said I forked the COPR and activated Fedora 23 as an option, would I
need to upload my own SRPM based on the git repository, or should I be
setting it up to pull automagically from elsewhere?
[1]
https://copr.fedorainfracloud.org/groups/g/nodejs-sig/coprs/
[2]
https://fedoraproject.org/wiki/Node.js
[3]
https://fedoraproject.org/wiki/Packaging:Node.js
[4]
https://copr.fedorainfracloud.org/coprs/g/nodejs-sig/nodejs-lts/build/181...
[5]
http://copr-dist-git.fedorainfracloud.org/cgit/@nodejs-sig/nodejs-lts/nod...
On Wed, Apr 27, 2016 at 8:38 AM Stephen Gallagher <sgallagh(a)redhat.com>
wrote:
On 04/27/2016 04:19 AM, Tom Hughes wrote:
> On 27/04/16 03:00, Stephen Gallagher wrote:
>
>> As for Option 1)? I think someone with more knowledge of the individual
modules
>> in Fedora (Tom Hughes? Jared Smith?) would need to figure out how many
modules
>> would be broken if we downgraded. If it's sufficiently small, I suppose
we could
>> epoch-bump nodejs and its virtual npm Provides: and go that route. I
don't love
>> that we will effectively been playing yo-yo with the version in F24,
but it
>> would be a solution...
>
> Off the top of my head I'm not aware of anything that requires 5.x and
for the
> most part I think people try to support at least 4.x and 5.x at the
moment, and
> often earlier versions as well.
>
> Tom
>
OK, I did some repoquery magic just now and came up with (unique-only):
nodejs(engine)
nodejs(engine) >= 0.1
nodejs(engine) >= 0.10
nodejs(engine) >= 0.10.0
nodejs(engine) >= 0.10.12
nodejs(engine) >= 0.10.15
nodejs(engine) >= 0.10.3
nodejs(engine) >= 0.10.36
nodejs(engine) >= 0.1.103
nodejs(engine) >= 0.12.0
nodejs(engine) >= 0.1.90
nodejs(engine) > 0.1.90
nodejs(engine) >= 0.2.0
nodejs(engine) >= 0.2.0-0
nodejs(engine) >= 0.2.4
nodejs(engine) >= 0.2.5
nodejs(engine) >= 0.3.0
nodejs(engine) >= 0.3.1
nodejs(engine) >= 0.3.6
nodejs(engine) >= 0.4
nodejs(engine) >= 0.4.
nodejs(engine) >= 0.4.0
nodejs(engine) >= 0.4.1
nodejs(engine) >= 0.4.2
nodejs(engine) >= 0.4.7
nodejs(engine) >= 0.4.9
nodejs(engine) >= 0.6
nodejs(engine) >= 0.6.0
nodejs(engine) >= 0.6.19
nodejs(engine) >= 0.6.3
nodejs(engine) >= 0.6.6
nodejs(engine) >= 0.8
nodejs(engine) >= 0.8.
nodejs(engine) >= 0.8.0
nodejs(engine) >= 0.8.19
nodejs(engine) >= 0.9.0
nodejs(engine) >= 4
nodejs(engine) >= 4.0.0
So according to this, we have nothing in the package collection that is
known to
require only 5.x or later. So that's a point in favor of the 4.x downgrade
approach.
I don't love the idea of regressing the versions post-Beta, but it's
starting to
look like the least-risky approach. We really have no idea what is going
to be
broken by 6.0 and I don't want to stick some poor volunteer with
maintaining
backports of a dead upstream release.
_______________________________________________
nodejs mailing list
nodejs(a)lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/nodejs@lists.fedoraproject.org