Re: Orphaned 215 packages

[Ben Rosser]

On Wed, May 13, 2020 at 3:56 AM Jamie Nguyen <j(a)jamielinux.com&gt; wrote:

>  Hi,
>
>  This is a follow up for this post:
>
>
> https://lists.fedoraproject.org/archives/list/[e-mail].o...
>
>  Below are the packages I've orphaned. See section [d] of the linked
>  email to see how many times each package is listed as Requires by
>  something else.
>
>  Most are Node.js packages, some still maintained via the 'nodejs-sig'
>  user, though 'nodejs-sig' can't own packages so I orphaned instead.
>
>
>  - compat-libuv010
>  - CutyCapt
>  - dateformat
>  - expresso
>  - jasmine-node
>  - js-json
>  - js-zlib
>  - marked
>  - mocha
>  - nodejs-abbrev
>  - nodejs-ain2
>  - nodejs-ansi
>  - nodejs-ansi-styles
>  - nodejs-archy
>  - nodejs-asap
>  - nodejs-asn1
>  - nodejs-assertplus
>  - nodejs-async
>  - nodejs-aws-sign
>  - nodejs-basic-auth-connect
>  - nodejs-batch
>  - nodejs-better-assert
>  - nodejs-bindings
>  - nodejs-block-stream
>  - nodejs-boom
>  - nodejs-buffer-crc32
>  - nodejs-buffer-equal
>  - nodejs-bunker
>  - nodejs-burrito
>  - nodejs-bytes
>  - nodejs-callsite
>  - nodejs-chalk
>  - nodejs-character-parser
>  - nodejs-charm
>  - nodejs-child-process-close
>  - nodejs-chmodr
>  - nodejs-chownr
>  - nodejs-cmd-shim
>  - nodejs-combined-stream
>  - nodejs-commander
>  - nodejs-component-emitter
>  - nodejs-config-chain
>  - nodejs-connect-timeout
>  - nodejs-console-dot-log
>  - nodejs-cookie
>  - nodejs-cookiejar
>  - nodejs-cookie-jar
>  - nodejs-cookie-parser
>  - nodejs-cookie-signature
>  - nodejs-couch-login
>  - nodejs-cryptiles
>  - nodejs-css
>  - nodejs-cssom
>  - nodejs-css-parse
>  - nodejs-css-stringify
>  - nodejs-csurf
>  - nodejs-ctype
>  - nodejs-cycle
>  - nodejs-debug
>  - nodejs-defined
>  - nodejs-delayed-stream
>  - nodejs-detective
>  - nodejs-diff
>  - nodejs-dryice
>  - nodejs-editor
>  - nodejs-ejs
>  - nodejs-escodegen
>  - nodejs-estraverse
>  - nodejs-esutils
>  - nodejs-eventemitter2
>  - nodejs-exit
>  - nodejs-expect-dot-js
>  - nodejs-express-session
>  - nodejs-faye-websocket
>  - nodejs-fileset
>  - nodejs-findup-sync
>  - nodejs-forever-agent
>  - nodejs-form-data
>  - nodejs-formidable
>  - nodejs-fresh
>  - nodejs-fstream
>  - nodejs-fstream-ignore
>  - nodejs-fstream-npm
>  - nodejs-generic-pool
>  - nodejs-getobject
>  - nodejs-github-url-from-git
>  - nodejs-glob
>  - nodejs-grip
>  - nodejs-growl
>  - nodejs-grunt-compare-size
>  - nodejs-grunt-contrib-concat
>  - nodejs-grunt-contrib-internal
>  - nodejs-grunt-contrib-uglify
>  - nodejs-grunt-contrib-watch
>  - nodejs-grunt-git-authors
>  - nodejs-gzip-size
>  - nodejs-has-color
>  - nodejs-hawk
>  - nodejs-hoek
>  - nodejs-hooker
>  - nodejs-http-signature
>  - nodejs-inherits1
>  - nodejs-ini
>  - nodejs-iso8601
>  - nodejs-isodate
>  - nodejs-jasmine-reporters
>  - nodejs-joose
>  - nodejs-joosex-namespace-depended
>  - nodejs-joosex-simplerequest
>  - nodejs-jscoverage
>  - nodejs-jsonfile
>  - nodejs-jsonify
>  - nodejs-json-stringify-safe
>  - nodejs-js-yaml
>  - nodejs-jwt-simple
>  - nodejs-keypress
>  - nodejs-lazystream
>  - nodejs-lockfile
>  - nodejs-markdown
>  - nodejs-maxmin
>  - nodejs-methods
>  - nodejs-mime
>  - nodejs-mimeparse
>  - nodejs-minimatch
>  - nodejs-minimist
>  - nodejs-morgan
>  - nodejs-ms
>  - nodejs-muffin
>  - nodejs-multiparty
>  - nodejs-mute-stream
>  - nodejs-nan0
>  - nodejs-ncp
>  - nodejs-node-int64
>  - nodejs-node-uuid
>  - nodejs-nopt
>  - nodejs-noptify
>  - nodejs-npmlog
>  - nodejs-npm-user-validate
>  - nodejs-oauth-sign
>  - nodejs-opener
>  - nodejs-optimist
>  - nodejs-opts
>  - nodejs-osenv
>  - nodejs-package
>  - nodejs-paperboy
>  - nodejs-parseurl
>  - nodejs-pause
>  - nodejs-pkginfo
>  - nodejs-pretty-bytes
>  - nodejs-promise
>  - nodejs-promzard
>  - nodejs-proto-list
>  - nodejs-pubcontrol
>  - nodejs-qs
>  - nodejs-range-parser
>  - nodejs-read
>  - nodejs-readdirp
>  - nodejs-read-package-json
>  - nodejs-reduce-component
>  - nodejs-repl
>  - nodejs-require-cs
>  - nodejs-requirejs
>  - nodejs-resolve
>  - nodejs-response-time
>  - odejs-response-time rpms
>  - nodejs-retry
>  - nodejs-rimraf
>  - nodejs-ronn
>  - nodejs-runforcover
>  - nodejs-sax
>  - nodejs-semver
>  - nodejs-serve-index
>  - nodejs-setimmediate
>  - nodejs-sha
>  - nodejs-shelljs
>  - nodejs-showdown
>  - nodejs-sigmund
>  - nodejs-slide
>  - nodejs-source-map
>  - nodejs-stack-trace
>  - nodejs-static-favicon
>  - nodejs-stream-counter
>  - nodejs-strip-ansi
>  - nodejs-superagent
>  - nodejs-supertest
>  - nodejs-tar
>  - nodejs-temp
>  - nodejs-temporary
>  - nodejs-testswarm
>  - nodejs-through
>  - nodejs-tiny-lr-fork
>  - nodejs-transformers
>  - nodejs-traverse
>  - nodejs-tunnel-agent
>  - nodejs-uglify-to-browserify
>  - nodejs-uid-number
>  - nodejs-underscore
>  - nodejs-underscore-dot-string
>  - nodejs-utile
>  - nodejs-vhost
>  - nodejs-walkdir
>  - nodejs-weak-map
>  - nodejs-websocket-driver
>  - nodejs-which
>  - nodejs-wordwrap
>  - nodejs-yamlish
>  - nodejs-zlib-browserify
>  - nodejs-zlibjs
>  - uglify-js1
>  - web-assets
>  
So... this is a lot of node.js packages, and I haven't really seen any
discussion of this on the lists. And at least some of these are possibly
important for other nodejs packages-- notably "mocha", which I suspect is
used in at least some packages to run unit tests (at the very least,
several of my nodejs packages use it to run unit tests...).

Has anyone in the nodejs SIG given any thought to picking any of these up?
Do we need some kind of Stewardship SIG-like effort to try and improve the
state of the node.js ecosystem in Fedora? It's probably no secret that a
lot of node packages are outdated and in less-than-fantastic shape...

I've been trying to maintain packages for a node application [1] and its
dependencies, and it's increasingly difficult due to old dependencies, even
when they're not FTBFS or FTI or orphaned. I don't have the bandwidth to
take over all of these, but I'd be willing to join some kind of collective
effort to improve things. As far as I can tell, most node.js specfiles are
pretty simple (in fact, they could probably be generated by a script), the
only problem is the coordination required to keep large dependency trees up
to date. Maybe it would be good to figure out something like:

a) Are there packages that people care about (e.g. applications or
webapps?) that actually use the nodejs modules currently in Fedora?
b) What's required to maintain those? e.g. dependencies or build-time tools
to run tests?
c) What can we do to keep that subset of packages alive and up to date?

Ben Rosser

[1] https://github.com/reactiflux/discord-irc

Orphaned 215 packages

[Jared K. Smith]

On Tue, Jun 16, 2020 at 3:41 PM Ben Rosser <rosser.bjr(a)gmail.com&gt; wrote:

>  So... this is a lot of node.js packages, and I haven't really
> seen any
>  discussion of this on the lists. And at least some of these are possibly
>  important for other nodejs packages-- notably "mocha", which I suspect is
>  used in at least some packages to run unit tests (at the very least,
>  several of my nodejs packages use it to run unit tests...).
>  
Indeed... I'd hate to see mocha disappear.  That being said, there's a
bunch of these other packages that can probably safely be retired -- I
pulled in a couple hundred NodeJS packages in my hard-headed attempt to get
NodeRED into Fedora for the IoT team a couple of years ago, but got bogged
down in dependency nightmares and ultimately gave up.  Since then, I've
been busy with my job and grad school to really spend a lot of time
worrying about NodeJS packages in Fedora, since I'm not a NodeJS
developer.  That being said, if there are packages like mocha that really
need to be maintained to keep the NodeJS ecosystem working in Fedora, I
could probably be persuaded to pick up a few more packages.

-Jared

Orphaned 215 packages

[Ben Rosser]

On Tue, Jun 16, 2020 at 5:38 PM Jared K. Smith <jsmith(a)fedoraproject.org&gt; wrote:
>  On Tue, Jun 16, 2020 at 3:41 PM Ben Rosser <rosser.bjr(a)gmail.com&gt; wrote:
> >
> > So... this is a lot of node.js packages, and I haven't really seen any discussion
> of this on the lists. And at least some of these are possibly important for other nodejs
> packages-- notably "mocha", which I suspect is used in at least some packages to
> run unit tests (at the very least, several of my nodejs packages use it to run unit
> tests...).
>
>
>  Indeed... I'd hate to see mocha disappear.  That being said, there's a bunch of
> these other packages that can probably safely be retired -- I pulled in a couple hundred
> NodeJS packages in my hard-headed attempt to get NodeRED into Fedora for the IoT team a
> couple of years ago, but got bogged down in dependency nightmares and ultimately gave up. 
> Since then, I've been busy with my job and grad school to really spend a lot of time
> worrying about NodeJS packages in Fedora, since I'm not a NodeJS developer.  That
> being said, if there are packages like mocha that really need to be maintained to keep the
> NodeJS ecosystem working in Fedora, I could probably be persuaded to pick up a few more
> packages.
>
>  -Jared 
Hi Jared,

That makes sense to me. Maybe the priority should be trying to keep
mocha alive, and eventually figuring out how to update it? The current
dependencies, according to repoqery, are as follows:

(npm(commander) >= 2.2.0 with npm(commander) < 3)
(npm(debug) >= 2.2.0 with npm(debug) < 3)
(npm(diff) >= 1.0.8 with npm(diff) < 2)
(npm(escape-string-regexp) >= 1.0.2 with npm(escape-string-regexp) < 2)
(npm(glob) >= 6.0.3 with npm(glob) < 7)
(npm(growl) >= 1.7.0 with npm(growl) < 2)
(npm(jade) >= 1.3.1 with npm(jade) < 2)
(npm(mkdirp) >= 0.5.0 with npm(mkdirp) < 0.6)
/usr/bin/env
nodejs(engine) >= 0.8.0
npm(supports-color)

I haven't looked further to see what the dependency tree is like for
each of these, but commander, debug, diff, glob, and growl are all
currently orphaned.

Ben