Re: [Pkg-javascript-devel] Bug#754551: ITP: node-ms -- milliseconds conversion utility
On Mon, Aug 4, 2014 at 6:13 PM, Andrew Kelley superjo...@gmail.com wrote: On Mon, Aug 4, 2014 at 6:06 PM, Marco d'Itri m...@linux.it wrote: If it makes sense to bundle multiple libraries in the same package which other packages may depend on then go for it. I understand. Here is an example of doing exactly this: http://anonscm.debian.org/cgit/pkg-javascript/node-chalk.git/tree/debian/watch However let me re-iterate that ms has 104 other modules depending on it: https://www.npmjs.org/package/ms 111 LOC is small but not trivial. I think this is not an example of a package that should be blocked. Looking at the NEW queue, I see that I have 2 packages that are trivially small and could be bundled with the project that depends on them: node-deflate-crc32-stream node-crc32-stream These packages are very small and the only thing that depends on them is node-zip-stream (which also depends on node-debug which is waiting on node-ms). Please delete these from the NEW queue and I will bundle them with node-zip-stream. The other packages of mine that are in there are *not* trivially small, and/or have many other packages depending on them. For these I believe the proper action is to accept the upload: node-connect-static - so far has only groovebasin depending on it. I can bundle it with groovebasin, but it's really an independent module. node-errno - has 27 completely unrelated modules depending on it. clearly should be separate node-groove - contains C++ bindings to libgroove and has lots of LOC. You should be happy about this one. node-music-library-index - separate from groovebasin because both client side code and server side code depend on it. trying to bundle this one would make it confusing or impossible to work with browserify, which groovebasin uses at build-time. node-mv - has 30 completely unrelated modules depending on it. clearly should be separate node-prr - node-errno and node-levelup both depend on this, both of which I am trying to get packaged up. Please tell me what further action I can take to move this process along. I've been working hard to package up a large application with many dependencies in accordance with Debian guidelines, and now it seems that I have hit an invisible wall and it's not clear who is responsible for it or what they want from me.
Re: [Pkg-javascript-devel] Bug#754551: ITP: node-ms -- milliseconds conversion utility
On Sat, Jul 12, 2014 at 3:57 AM, Frederic Peters fpet...@debian.org wrote:
Steve McIntyre wrote:
I've seen ITPs for a massive set of tiny-looking node libraries go
past on -devel in the last few months, so I thought it was about time
I looked at one. I'm a bit worried by what I've seen, considering
typical discussions in the past about really small packages.
I am largely responsible for this. However many of the ITPs I have filed I
managed to avoid as (indirect) dependencies by submitting patches upstream
and when appropriate, inlining the dependency. Most of the problematic ones
you saw are closed now, including the 2 at the end of this email.
[...]
tack:~/debian/ms.js$ wc -l index.js
111 index.js
Am I missing something, or is the working code in this package really
just 111 lines? Why isn't this bundled up into something more
reasonable in size for the packaging system?
Consider my perspective for a moment here. I am trying to package
groovebasin, which depends on various modules:
groovebasin (1.2.0) # waiting on dependencies
...many more dependencies...
├─ zip-stream (~0.3.0) # waiting for node-debug to update
│ └─ debug (~1.0.2) # l3on is waiting for node-ms in the NEW queue
│ └─ ms (~0.6.2) # waiting in the NEW queue...
...many more dependencies...
So now I'm waiting for node-ms in the NEW queue and people are complaining
that 111 lines is too small for a code module?
What do you expect me to do? It would be very easy to just bundle all
node_modules with the package but that is against Debian guidelines. Each
dependency must track upstream. So that's exactly what we're doing and
we're getting flak for it.
It seems that Debian wants 2 contradictory things from me at the same time.
ITP: node-ansi-regex
$ git clone https://github.com/sindresorhus/ansi-regex
$ cat ansi-regex/index.js
'use strict';
module.exports = function () {
return /\u001b\[(?:[0-9]{1,3}(?:;[0-9]{1,3})*)?[m|K]/g;
};
ITP: node-quotemeta
$ git clone https://github.com/substack/quotemeta.git
$ cat quotemeta/index.js
module.exports = function (str) {
return String(str).replace(/(\W)/g, '\\$1');
};
These 2 are indeed stupidly small. I have managed to work around packaging
these 2 modules up and closed the ITPs.
I have taken a lot of time to try to avoid packaging modules for Debian
which could be avoided. I have done this by painstakingly getting patches
merged in many upstream projects to change dependencies to better ones, or
fewer ones. When I started it looked like there were about 80 packages to
create, but I have brought that number down by a factor of 2.
I do not think that node-ms is stupidly small. 104 other packages depend on
it in the NPM registry: https://www.npmjs.org/package/ms
Please consider uploading node-ms and know that I am aware of the pain of
small packages and I am working hard to strike the balance between properly
tracking upstream and avoiding cruft.
Regards,
Andrew
Re: [Pkg-javascript-devel] Bug#754551: ITP: node-ms -- milliseconds conversion utility
On Aug 05, Andrew Kelley superjo...@gmail.com wrote: What do you expect me to do? It would be very easy to just bundle all node_modules with the package but that is against Debian guidelines. Each dependency must track upstream. So that's exactly what we're doing and we're getting flak for it. It seems that Debian wants 2 contradictory things from me at the same time. Not really: the really iportant goal is to avoid code duplication. If it makes sense to bundle multiple libraries in the same package which other packages may depend on then go for it. -- ciao, Marco signature.asc Description: Digital signature
Re: [Pkg-javascript-devel] Bug#754551: ITP: node-ms -- milliseconds conversion utility
On Mon, Aug 4, 2014 at 6:06 PM, Marco d'Itri m...@linux.it wrote: If it makes sense to bundle multiple libraries in the same package which other packages may depend on then go for it. I understand. Here is an example of doing exactly this: http://anonscm.debian.org/cgit/pkg-javascript/node-chalk.git/tree/debian/watch However let me re-iterate that ms has 104 other modules depending on it: https://www.npmjs.org/package/ms 111 LOC is small but not trivial. I think this is not an example of a package that should be blocked. Regards, Andrew
Re: Bug#754551: ITP: node-ms -- milliseconds conversion utility
❦ 12 juillet 2014 23:08 +0100, Steve McIntyre st...@einval.com : And I've got to ask: for the couple of trivial examples that Frederick pointed out - why on earth do these even exist as libraries instead of being inlined wherever they're needed? Because, in node, a library is cheap and the functionality get unit tested. That's why there are so many dependencies in this ecosystem. Inlining is solving the wrong problem. -- printk(MASQUERADE: No route: Rusty's brain broke!\n); 2.4.3. linux/net/ipv4/netfilter/ipt_MASQUERADE.c signature.asc Description: PGP signature
Re: Bug#754551: ITP: node-ms -- milliseconds conversion utility
On Sun, 13 Jul 2014 09:26:38 +0200 Vincent Bernat ber...@debian.org wrote: ❦ 12 juillet 2014 23:08 +0100, Steve McIntyre st...@einval.com : And I've got to ask: for the couple of trivial examples that Frederick pointed out - why on earth do these even exist as libraries instead of being inlined wherever they're needed? Because, in node, a library is cheap and the functionality get unit tested. That's why there are so many dependencies in this ecosystem. Unit tests do not preclude inlining. Unit tests do not preclude aggregation. It's all just about multiple blocks of code in dedicated directories inside a single source package building a single binary package from which any other package can pick and choose the bits that package needs. Just what is wrong with one binary package putting lots of js in /usr/share/javascript/$library/$version/ and using symlinks in the bigger package to pull in the files that package wants? It's more work for the maintainers but it's less work for users - which is the right way around. Inlining is solving the wrong problem. Tiny packages are the wrong solution. -- Neil Williams = http://www.linux.codehelp.co.uk/ signature.asc Description: PGP signature
Re: Bug#754551: ITP: node-ms -- milliseconds conversion utility
At Sun, 13 Jul 2014 09:26:38 +0200, Vincent Bernat wrote: ❦ 12 juillet 2014 23:08 +0100, Steve McIntyre st...@einval.com : And I've got to ask: for the couple of trivial examples that Frederick pointed out - why on earth do these even exist as libraries instead of being inlined wherever they're needed? Because, in node, a library is cheap and the functionality get unit tested. That's why there are so many dependencies in this ecosystem. You have all the extra metadata, extra git repository, extra dependency tracking, etc. no matter how 'cheap' a library is. And as far as I understand npm (correct me if I'm wrong, I don't use npm very often), it will install dependencies in a nested way, so if app1 use library1 and library2, and both those libraries use tinylibrary1, tinylibrary2 and tinylibrary3, then those 3 tiny libraries will be installed both under library1 and library2. I wouldn't really call that cheap. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/87wqbhy54i.wl%jer...@dekkers.ch
Re: Bug#754551: ITP: node-ms -- milliseconds conversion utility
❦ 13 juillet 2014 11:34 +0200, Jeroen Dekkers jer...@dekkers.ch : And I've got to ask: for the couple of trivial examples that Frederick pointed out - why on earth do these even exist as libraries instead of being inlined wherever they're needed? Because, in node, a library is cheap and the functionality get unit tested. That's why there are so many dependencies in this ecosystem. You have all the extra metadata, extra git repository, extra dependency tracking, etc. no matter how 'cheap' a library is. It still makes the library cheap. Those extra stuff are why the library is done in the first place. They allow people to find simple stuff without reimplementing it (usually with additional bugs). That's exacerbated by the fact that the standard library is inexistent with javascript and that the one that comes with node is quite small. Looking at the stats of this trivial library: https://www.npmjs.org/package/ms I see it is quite popular and used by many (101) projects. That's projects finding the library useful enough to not inline it. And as far as I understand npm (correct me if I'm wrong, I don't use npm very often), it will install dependencies in a nested way, so if app1 use library1 and library2, and both those libraries use tinylibrary1, tinylibrary2 and tinylibrary3, then those 3 tiny libraries will be installed both under library1 and library2. I wouldn't really call that cheap. You are right. That's their way to not have to really manage versioning. But that's the same cost when inlining. And that's irrelevant in the Debian case since we don't nest. -- Treat end of file conditions in a uniform manner. - The Elements of Programming Style (Kernighan Plauger) signature.asc Description: PGP signature
Re: Bug#754551: ITP: node-ms -- milliseconds conversion utility
❦ 13 juillet 2014 08:50 +0100, Neil Williams codeh...@debian.org : And I've got to ask: for the couple of trivial examples that Frederick pointed out - why on earth do these even exist as libraries instead of being inlined wherever they're needed? Because, in node, a library is cheap and the functionality get unit tested. That's why there are so many dependencies in this ecosystem. Unit tests do not preclude inlining. Unit tests do not preclude aggregation. It's all just about multiple blocks of code in dedicated directories inside a single source package building a single binary package from which any other package can pick and choose the bits that package needs. Just what is wrong with one binary package putting lots of js in /usr/share/javascript/$library/$version/ and using symlinks in the bigger package to pull in the files that package wants? Aggregation is not inlining. I was talking about inlining. I have no opinion about aggregation. -- /* Thanks to Rob `CmdrTaco' Malda for not influencing this code in any * way. */ 2.4.3 linux/net/core/netfilter.c signature.asc Description: PGP signature
Bug#754551: ITP: node-ms -- milliseconds conversion utility
Package: wnpp Severity: wishlist Owner: Leo Iannacone l...@ubuntu.com X-Debbugs-CC: debian-devel@lists.debian.org * Package name: node-ms Version : 0.6.2 Upstream Author : Guillermo Rauch rau...@gmail.com * URL : https://github.com/guille/ms.js * License : Expat Programming Lang: JavaScript Description : milliseconds conversion utility - Node.js module This module provides a tiny milliseconds conversion utility able to transorm a string with a valid time unit to the equivalent number of milliseconds and vice versa. . Node.js is an event-based server-side JavaScript engine. . Node.js is an event-based server-side JavaScript engine. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/53c10a02.c759b40a.5c57.9...@mx.google.com
Re: Bug#754551: ITP: node-ms -- milliseconds conversion utility
l...@ubuntu.com wrote: Package: wnpp Severity: wishlist Owner: Leo Iannacone l...@ubuntu.com X-Debbugs-CC: debian-devel@lists.debian.org * Package name: node-ms Version : 0.6.2 Upstream Author : Guillermo Rauch rau...@gmail.com * URL : https://github.com/guille/ms.js * License : Expat Programming Lang: JavaScript Description : milliseconds conversion utility - Node.js module This module provides a tiny milliseconds conversion utility able to transorm a string with a valid time unit to the equivalent number of milliseconds and vice versa. . Node.js is an event-based server-side JavaScript engine. . Node.js is an event-based server-side JavaScript engine. I've seen ITPs for a massive set of tiny-looking node libraries go past on -devel in the last few months, so I thought it was about time I looked at one. I'm a bit worried by what I've seen, considering typical discussions in the past about really small packages. tack:~/debian/ms.js$ ls -al total 52 drwxr-xr-x 4 steve users 4096 Jul 12 11:29 ./ drwxr-xr-x 112 steve users 4096 Jul 12 11:29 ../ drwxr-xr-x 8 steve users 4096 Jul 12 11:29 .git/ -rw-r--r-- 1 steve users 13 Jul 12 11:29 .gitignore -rw-r--r-- 1 steve users 53 Jul 12 11:29 .npmignore -rw-r--r-- 1 steve users 1026 Jul 12 11:29 History.md -rw-r--r-- 1 steve users 1097 Jul 12 11:29 LICENSE -rw-r--r-- 1 steve users 110 Jul 12 11:29 Makefile -rw-r--r-- 1 steve users 814 Jul 12 11:29 README.md -rw-r--r-- 1 steve users 223 Jul 12 11:29 component.json -rw-r--r-- 1 steve users 2025 Jul 12 11:29 index.js -rw-r--r-- 1 steve users 360 Jul 12 11:29 package.json drwxr-xr-x 2 steve users 4096 Jul 12 11:29 test/ tack:~/debian/ms.js$ wc -l index.js 111 index.js Am I missing something, or is the working code in this package really just 111 lines? Why isn't this bundled up into something more reasonable in size for the packaging system? -- Steve McIntyre, Cambridge, UK.st...@einval.com Support the Campaign for Audiovisual Free Expression: http://www.eff.org/cafe/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/e1x5ueq-zx...@mail.einval.com
Re: Bug#754551: ITP: node-ms -- milliseconds conversion utility
On 12 July 2014 12:35, Steve McIntyre st...@einval.com wrote: l...@ubuntu.com wrote: Package: wnpp Severity: wishlist Owner: Leo Iannacone l...@ubuntu.com X-Debbugs-CC: debian-devel@lists.debian.org * Package name: node-ms Version : 0.6.2 Upstream Author : Guillermo Rauch rau...@gmail.com * URL : https://github.com/guille/ms.js * License : Expat Programming Lang: JavaScript Description : milliseconds conversion utility - Node.js module This module provides a tiny milliseconds conversion utility able to transorm a string with a valid time unit to the equivalent number of milliseconds and vice versa. . Node.js is an event-based server-side JavaScript engine. . Node.js is an event-based server-side JavaScript engine. I've seen ITPs for a massive set of tiny-looking node libraries go past on -devel in the last few months, so I thought it was about time I looked at one. I'm a bit worried by what I've seen, considering typical discussions in the past about really small packages. tack:~/debian/ms.js$ ls -al total 52 drwxr-xr-x 4 steve users 4096 Jul 12 11:29 ./ drwxr-xr-x 112 steve users 4096 Jul 12 11:29 ../ drwxr-xr-x 8 steve users 4096 Jul 12 11:29 .git/ -rw-r--r-- 1 steve users 13 Jul 12 11:29 .gitignore -rw-r--r-- 1 steve users 53 Jul 12 11:29 .npmignore -rw-r--r-- 1 steve users 1026 Jul 12 11:29 History.md -rw-r--r-- 1 steve users 1097 Jul 12 11:29 LICENSE -rw-r--r-- 1 steve users 110 Jul 12 11:29 Makefile -rw-r--r-- 1 steve users 814 Jul 12 11:29 README.md -rw-r--r-- 1 steve users 223 Jul 12 11:29 component.json -rw-r--r-- 1 steve users 2025 Jul 12 11:29 index.js -rw-r--r-- 1 steve users 360 Jul 12 11:29 package.json drwxr-xr-x 2 steve users 4096 Jul 12 11:29 test/ tack:~/debian/ms.js$ wc -l index.js 111 index.js Am I missing something, or is the working code in this package really just 111 lines? Why isn't this bundled up into something more reasonable in size for the packaging system? No, you're right. It is really small. But, after discussing this in JavaScript team we ended up that it is better have separated packages, instead of having a big nodejs-common (or whatever) package, in order to properly track upstream releases individually. Cheers. L. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CACzqv1eryTPLQyV5q-2AH+NGjKN1M2KBPY0_yCDoz-gS=4_...@mail.gmail.com
Re: Bug#754551: ITP: node-ms -- milliseconds conversion utility
Steve McIntyre wrote:
I've seen ITPs for a massive set of tiny-looking node libraries go
past on -devel in the last few months, so I thought it was about time
I looked at one. I'm a bit worried by what I've seen, considering
typical discussions in the past about really small packages.
[...]
tack:~/debian/ms.js$ wc -l index.js
111 index.js
Am I missing something, or is the working code in this package really
just 111 lines? Why isn't this bundled up into something more
reasonable in size for the packaging system?
Indeed, I also recently looked at some, but didn't speak about it;
just like we have LaTeX packages including a serie of CTAN packages,
I believe it would make sense to have the same sort of thing for
node.js modules.
I have CCed pkg-javascript-de...@lists.alioth.debian.org.
Fred
ITP: node-ansi-regex
$ git clone https://github.com/sindresorhus/ansi-regex
$ cat ansi-regex/index.js
'use strict';
module.exports = function () {
return /\u001b\[(?:[0-9]{1,3}(?:;[0-9]{1,3})*)?[m|K]/g;
};
ITP: node-quotemeta
$ git clone https://github.com/substack/quotemeta.git
$ cat quotemeta/index.js
module.exports = function (str) {
return String(str).replace(/(\W)/g, '\\$1');
};
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140712105745.ga13...@0d.be
Re: Bug#754551: ITP: node-ms -- milliseconds conversion utility
On Sat, Jul 12, 2014 at 12:55:02PM +0200, Leo Iannacone wrote: On 12 July 2014 12:35, Steve McIntyre st...@einval.com wrote: tack:~/debian/ms.js$ wc -l index.js 111 index.js Am I missing something, or is the working code in this package really just 111 lines? Why isn't this bundled up into something more reasonable in size for the packaging system? No, you're right. It is really small. But, after discussing this in JavaScript team we ended up that it is better have separated packages, instead of having a big nodejs-common (or whatever) package, in order to properly track upstream releases individually. Right. Did you discuss that with ftpmaster or anybody else outside of the javascript team? There's typically been a consensus against very small packages containing just a single script or piece of code so small that the packaging metadata is going to be as big as (or bigger than!) the package contents. The packaging overhead hits every single user of Debian... -- Steve McIntyre, Cambridge, UK.st...@einval.com Mature Sporty Personal More Innovation More Adult A Man in Dandism Powered Midship Specialty -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140712110328.gx18...@einval.com
Re: Bug#754551: ITP: node-ms -- milliseconds conversion utility
Le samedi 12 juillet 2014 à 12:03 +0100, Steve McIntyre a écrit : On Sat, Jul 12, 2014 at 12:55:02PM +0200, Leo Iannacone wrote: On 12 July 2014 12:35, Steve McIntyre st...@einval.com wrote: tack:~/debian/ms.js$ wc -l index.js 111 index.js Am I missing something, or is the working code in this package really just 111 lines? Why isn't this bundled up into something more reasonable in size for the packaging system? No, you're right. It is really small. But, after discussing this in JavaScript team we ended up that it is better have separated packages, instead of having a big nodejs-common (or whatever) package, in order to properly track upstream releases individually. Right. Did you discuss that with ftpmaster or anybody else outside of the javascript team? There's typically been a consensus against very small packages containing just a single script or piece of code so small that the packaging metadata is going to be as big as (or bigger than!) the package contents. The packaging overhead hits every single user of Debian... Can you give reference(s) to that consensus ? Can you be more specific about the way small packages hit users ? (numbers, please). Jérémy. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1405170874.14141.3.camel@imac.chaumes
Re: Bug#754551: ITP: node-ms -- milliseconds conversion utility
On Sat, Jul 12, 2014 at 12:55:02PM +0200, Leo Iannacone wrote: On 12 July 2014 12:35, Steve McIntyre st...@einval.com wrote: l...@ubuntu.com wrote: Package: wnpp Severity: wishlist Owner: Leo Iannacone l...@ubuntu.com X-Debbugs-CC: debian-devel@lists.debian.org * Package name: node-ms Version : 0.6.2 Upstream Author : Guillermo Rauch rau...@gmail.com * URL : https://github.com/guille/ms.js * License : Expat Programming Lang: JavaScript Description : milliseconds conversion utility - Node.js module This module provides a tiny milliseconds conversion utility able to transorm a string with a valid time unit to the equivalent number of milliseconds and vice versa. . Node.js is an event-based server-side JavaScript engine. . Node.js is an event-based server-side JavaScript engine. I've seen ITPs for a massive set of tiny-looking node libraries go past on -devel in the last few months, so I thought it was about time I looked at one. I'm a bit worried by what I've seen, considering typical discussions in the past about really small packages. tack:~/debian/ms.js$ ls -al total 52 drwxr-xr-x 4 steve users 4096 Jul 12 11:29 ./ drwxr-xr-x 112 steve users 4096 Jul 12 11:29 ../ drwxr-xr-x 8 steve users 4096 Jul 12 11:29 .git/ -rw-r--r-- 1 steve users 13 Jul 12 11:29 .gitignore -rw-r--r-- 1 steve users 53 Jul 12 11:29 .npmignore -rw-r--r-- 1 steve users 1026 Jul 12 11:29 History.md -rw-r--r-- 1 steve users 1097 Jul 12 11:29 LICENSE -rw-r--r-- 1 steve users 110 Jul 12 11:29 Makefile -rw-r--r-- 1 steve users 814 Jul 12 11:29 README.md -rw-r--r-- 1 steve users 223 Jul 12 11:29 component.json -rw-r--r-- 1 steve users 2025 Jul 12 11:29 index.js -rw-r--r-- 1 steve users 360 Jul 12 11:29 package.json drwxr-xr-x 2 steve users 4096 Jul 12 11:29 test/ tack:~/debian/ms.js$ wc -l index.js 111 index.js Am I missing something, or is the working code in this package really just 111 lines? Why isn't this bundled up into something more reasonable in size for the packaging system? No, you're right. It is really small. But, after discussing this in JavaScript team we ended up that it is better have separated packages, instead of having a big nodejs-common (or whatever) package, in order to properly track upstream releases individually. How much do you think it will change in the foreseeable future? If there are frequent changes to those 111 lines, I am buying your argument, but if we are talking about 1-2 updates a year, a js-bundle package (which itself could be updated every couple of weeks unless major bugs or security issues pop up) might be more worthwhile. Michael -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140712131527.gw23...@raptor.chemicalconnection.dyndns.org
Re: Bug#754551: ITP: node-ms -- milliseconds conversion utility
On 12 July 2014 15:15, Michael Banck mba...@debian.org wrote: On Sat, Jul 12, 2014 at 12:55:02PM +0200, Leo Iannacone wrote: On 12 July 2014 12:35, Steve McIntyre st...@einval.com wrote: l...@ubuntu.com wrote: Package: wnpp Severity: wishlist Owner: Leo Iannacone l...@ubuntu.com X-Debbugs-CC: debian-devel@lists.debian.org * Package name: node-ms Version : 0.6.2 Upstream Author : Guillermo Rauch rau...@gmail.com * URL : https://github.com/guille/ms.js * License : Expat Programming Lang: JavaScript Description : milliseconds conversion utility - Node.js module This module provides a tiny milliseconds conversion utility able to transorm a string with a valid time unit to the equivalent number of milliseconds and vice versa. . Node.js is an event-based server-side JavaScript engine. . Node.js is an event-based server-side JavaScript engine. I've seen ITPs for a massive set of tiny-looking node libraries go past on -devel in the last few months, so I thought it was about time I looked at one. I'm a bit worried by what I've seen, considering typical discussions in the past about really small packages. tack:~/debian/ms.js$ ls -al total 52 drwxr-xr-x 4 steve users 4096 Jul 12 11:29 ./ drwxr-xr-x 112 steve users 4096 Jul 12 11:29 ../ drwxr-xr-x 8 steve users 4096 Jul 12 11:29 .git/ -rw-r--r-- 1 steve users 13 Jul 12 11:29 .gitignore -rw-r--r-- 1 steve users 53 Jul 12 11:29 .npmignore -rw-r--r-- 1 steve users 1026 Jul 12 11:29 History.md -rw-r--r-- 1 steve users 1097 Jul 12 11:29 LICENSE -rw-r--r-- 1 steve users 110 Jul 12 11:29 Makefile -rw-r--r-- 1 steve users 814 Jul 12 11:29 README.md -rw-r--r-- 1 steve users 223 Jul 12 11:29 component.json -rw-r--r-- 1 steve users 2025 Jul 12 11:29 index.js -rw-r--r-- 1 steve users 360 Jul 12 11:29 package.json drwxr-xr-x 2 steve users 4096 Jul 12 11:29 test/ tack:~/debian/ms.js$ wc -l index.js 111 index.js Am I missing something, or is the working code in this package really just 111 lines? Why isn't this bundled up into something more reasonable in size for the packaging system? No, you're right. It is really small. But, after discussing this in JavaScript team we ended up that it is better have separated packages, instead of having a big nodejs-common (or whatever) package, in order to properly track upstream releases individually. How much do you think it will change in the foreseeable future? If there are frequent changes to those 111 lines, I am buying your argument, but if we are talking about 1-2 updates a year, a js-bundle package (which itself could be updated every couple of weeks unless major bugs or security issues pop up) might be more worthwhile. Michael I have no idea about how frequently upstream will release a new version.. I think 1-2 updates per year as you said. Anyway I still prefer manage modules separately, I don't see any reason to make a common package.. And common to what? Node.js?? Express framework (since these are all dependencies for it)? It makes no sense -at least- to me. Best, Leo. -- Ubuntu Member - http://launchpad.net/~l3on Home Page - http://leoiannacone.com GPG Key Id - 0xD282FC25 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/caczqv1cz9ptsh1+tf5szqzaawzaofmff4sojt7uxoyd4m25...@mail.gmail.com
Re: Bug#754551: ITP: node-ms -- milliseconds conversion utility
Steve McIntyre st...@einval.com writes: Right. Did you discuss that with ftpmaster or anybody else outside of the javascript team? There's typically been a consensus against very small packages containing just a single script or piece of code so small that the packaging metadata is going to be as big as (or bigger than!) the package contents. The packaging overhead hits every single user of Debian... FWIW, the Perl team has recently gone through the same discussion, including with the ftp team, and has started breaking apart some large module collections into individual packages for the same reasons cited here. Tracking upstream releases in merged packages is quite painful. I'd really like to see us solve this problem by figuring out a better metadata distribution system (and IIRC some progress was made on that front recently) than in making life more difficult for packagers. Although if someone came up with a really elegant and scalable solution to merging multiple upstream releases into a Debian source package, that may work too. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/87mwceze97@windlord.stanford.edu
Re: Bug#754551: ITP: node-ms -- milliseconds conversion utility
Frederic Peters fpet...@debian.org writes: Indeed, I also recently looked at some, but didn't speak about it; just like we have LaTeX packages including a serie of CTAN packages, I believe it would make sense to have the same sort of thing for node.js modules. The CTAN case is a little bit different, as I understand it, because our actual upstream is TeXLive, which is already doing that merging for us and provides us with a clear upstream to use. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/87ion2ze7u@windlord.stanford.edu
Bootstrapping also increases the package count (was: Re: Bug#754551: ITP: node-ms -- milliseconds conversion utility)
Hi, Quoting Russ Allbery (2014-07-12 19:19:16) I'd really like to see us solve this problem by figuring out a better metadata distribution system (and IIRC some progress was made on that front recently) than in making life more difficult for packagers. which progress is that? With bootstrapping we also have the problem that we often have to increase the package count with very small packages as it is often required to split a package so that - one part of it can be multiarched (to be able to satisfy cross build dependencies) - or so that the content of the produced binary package of a stage1 profile build is not different from the full build (for example by splitting a foo-plugins package into foo-plugins-nogtk and foo-plugins-gtk) So we would also like to not run into the problem of making people's life harder because we increase the amount of package meta data too much. cheers, josch -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140712190136.31130.49432@hoothoot
Re: Bug#754551: ITP: node-ms -- milliseconds conversion utility
On Sat, 12 Jul 2014 16:12:17 +0200 Leo Iannacone l...@ubuntu.com wrote: Am I missing something, or is the working code in this package really just 111 lines? Why isn't this bundled up into something more reasonable in size for the packaging system? No, you're right. It is really small. But, after discussing this in JavaScript team we ended up that it is better have separated packages, instead of having a big nodejs-common (or whatever) package, in order to properly track upstream releases individually. It's not the best option for the archive or for any of the users of Debian. Tiny packages like this hurt *every* Debian user by padding the Packages file with many times the content of the package. Every user gets that hit whether they use the package or not. Worse, every user gets hit every time apt update is run - not just on the main system but in every chroot, on every mirror, on every buildd. I don't appreciate my 20 or 30 build environments getting hit every single time I run a build merely for your convenience. It's very inconvenient for everyone else but this is the only chance to complain about it. Anyway I still prefer manage modules separately, I don't see any reason to make a common package.. Because tiny packages hurt the archive and hurt all users. That's more than enough reason. And common to what? Node.js?? Express framework (since these are all dependencies for it)? Whatever uses it. Aggregate multiple upstreams into one source package and build one binary then ITP that. This binary then becomes a dependency of whatever needs any of the content. That way, only packages which use the code are affected. If you can't do that, embed everything needed and spin out a single binary from whichever one is the unlucky reverse dependency. That way, the only extra content is a few lines in debian/copyright. Whatever is done, aggregation is the key. It makes no sense -at least- to me. Think of people outside your own team. Think of everyone using apt. -- Neil Williams = http://www.linux.codehelp.co.uk/ signature.asc Description: PGP signature
Re: Bug#754551: ITP: node-ms -- milliseconds conversion utility
l...@ubuntu.com wrote: On 12 July 2014 15:15, Michael Banck mba...@debian.org wrote: On Sat, Jul 12, 2014 at 12:55:02PM +0200, Leo Iannacone wrote: But, after discussing this in JavaScript team we ended up that it is better have separated packages, instead of having a big nodejs-common (or whatever) package, in order to properly track upstream releases individually. How much do you think it will change in the foreseeable future? If there are frequent changes to those 111 lines, I am buying your argument, but if we are talking about 1-2 updates a year, a js-bundle package (which itself could be updated every couple of weeks unless major bugs or security issues pop up) might be more worthwhile. I have no idea about how frequently upstream will release a new version.. I think 1-2 updates per year as you said. Anyway I still prefer manage modules separately, I don't see any reason to make a common package.. And common to what? Node.js?? Express framework (since these are all dependencies for it)? It makes no sense -at least- to me. For such small (and obvious?) code in library packages, how many other packages are going to depend on or use them? If the Express framework is the key/only user, either bundle them with it or as one separate package that it depends on? Is there no node equivalent of the standard library where these could be attached? And I've got to ask: for the couple of trivial examples that Frederick pointed out - why on earth do these even exist as libraries instead of being inlined wherever they're needed? -- Steve McIntyre, Cambridge, UK.st...@einval.com Support the Campaign for Audiovisual Free Expression: http://www.eff.org/cafe/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/e1x65t3-00048y...@mail.einval.com
Re: Bug#754551: ITP: node-ms -- milliseconds conversion utility
kapo...@melix.org wrote: Le samedi 12 juillet 2014 à 12:03 +0100, Steve McIntyre a écrit : Right. Did you discuss that with ftpmaster or anybody else outside of the javascript team? There's typically been a consensus against very small packages containing just a single script or piece of code so small that the packaging metadata is going to be as big as (or bigger than!) the package contents. The packaging overhead hits every single user of Debian... Can you give reference(s) to that consensus ? Not off the top of my head, but it's come up a number of times in the last few years if you want to dig in the archives. Can you be more specific about the way small packages hit users ? (numbers, please). Every single user ends up downloading, storing and processing a larger amount of metadata in the Packages files. That's an issue. Storage might be cheap for most people, but not for everybody. Extra bandwidth to transfer the extra: ditto. And the extra processing needed on every invocation of apt and dpkg and the other tools slows everything down. All of these arguments have been made before - see previous threads. -- Steve McIntyre, Cambridge, UK.st...@einval.com Support the Campaign for Audiovisual Free Expression: http://www.eff.org/cafe/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/e1x65yb-0004dg...@mail.einval.com
