Re: [Pkg-javascript-devel] node packages in NEW
Le 10/09/2018 à 07:59, Bastien ROUCARIES a écrit : > On Mon, Sep 10, 2018 at 7:33 AM Xavier wrote: >> >> Le 09/09/2018 à 23:36, Bastien ROUCARIES a écrit : >>> On Sat, Sep 8, 2018 at 6:17 PM Xavier wrote: Le 07/09/2018 à 16:36, Xavier a écrit : > Le 07/09/2018 à 13:38, Bastien ROUCARIES a écrit : >> On Thu, Sep 6, 2018 at 9:45 PM Thorsten Alteholz >> wrote: >>> >>> Hi Bastien, >>> >>> On Wed, 5 Sep 2018, Bastien ROUCARIES wrote: > - put together packages that belong together; I am not sure here, > but > wouldn't it be fine to have just one package node-d3 or node-babel > that contains all corresponding modules (though their different > versions > might create problems in keeping track of them)? I strongly oppose to keep different version.# >>> >>> I don't meant to have different versions of one package here, but >>> bundling several packages with different versions, so that it might not >>> be >>> clear what version the resulting package might get. >> >> I agree with this maybe we could get something like: >> mainpackage+embded-nameembded1-version+embded-namembdedversion2-version+version >> ? >> >> Bastien > > Hello, > > I've written a little draft: > https://wiki.debian.org/Javascript/GroupedSourcePackageProxy I've updated draft to build a stateless proxy: DB was a bad idea since it can be modified at each request. I started to build groupedsources.cgi. The function to build grouped upstream sources works. Now I'm going to write the download part. When ready, you will be able to test with node-tap, simply by changing debian/watch. >>> >>> No I will not use as is. Actually node-tap use upstream tar ball >>> renamed as per dpkg spec [1]. >>> >>> You solution use a repack... >>> >>> >>> uscan support multiple tar (in V4) but only with one version. Your >>> redirector could help by fixing the version problem. >> >> OK, my redirector is ready. It provides all component with the same >> version. Example of debian/watch: >> >> # Main >> https://qa.debian.org/cgi-bin/groupedsources.cgi?upstream=npmjs/nodedbi+nmpjs/own-or >> \ >> .*=mainUpstream-(\d.*)\.(?:tgz|tar\.(?:gz|bz2|xz)) >> # Component own-or >> opts=component=own-or \ >> https://qa.debian.org/cgi-bin/groupedsources.cgi?upstream=npmjs/nodedbi+nmpjs/own-or=own-or; >> \ >> .*=mainUpstream-(\d.*)\.(?:tgz|tar\.(?:gz|bz2|xz)) >> ... >> >> Downloads are redirected to npmjs and not built by groupedsources.cgi >> >>> A minor point about version, it should be + instead of ~. Embded >>> version are after normal version. I think the best will be to use +~ >>> to separate embed version. It is unlikey someone will use +~ and it is >>> a perfectly legal string. >>> >>> so I will recommend as version >>> mainversion+dsembded+~version1+~version2+~version3 >> >> OK, to simplify version, the second part is a cumulative version (sum of >> digits of each component). Example: 1.2.3+~6.2.4 >> There is a "over" parameter in CGI to increase first digit (in case it >> was decreased due to the removal of 1 component) > I prefer the previous version of version string. Sorry no sum please. Be > stupid. > If this proposition is acceptable, I'll propose a policy patch to authorize JS grouped sources and a JS policy patch for details. >>> >>> [1] >>> https://raphaelhertzog.com/2010/09/07/how-to-use-multiple-upstream-tarballs-in-debian-source-packages/ OK, it works now. I've rebuild node-mongodb including its 2 dependencies not yet available. If you want to test: * install groupedsources.cgi in your local /usr/lib/cgi-bin: https://salsa.debian.org/yadd/qa/blob/master/cgi-bin/groupedsources.cgi * clone https://salsa.debian.org/js-team/node-mongodb * `git checkout groupedsources` This works: * `uscan -dd` installs the 3 sources * sbuild or `gbp buildpackage` installs the 3 node modules Note: * since mongodb build doesn't need dependencies, they are not installed in node_modules directory during build. A simple mkdir+ln-s would be enough if this was needed * debian/copyright not yet updated (=> lintian warnings) * a suffix may be required here Any advice or contribution are welcome! Cheers, Xavier -- Pkg-javascript-devel mailing list Pkg-javascript-devel@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel
Re: [Pkg-javascript-devel] node packages in NEW
On Mon, Sep 10, 2018 at 7:33 AM Xavier wrote: > > Le 09/09/2018 à 23:36, Bastien ROUCARIES a écrit : > > On Sat, Sep 8, 2018 at 6:17 PM Xavier wrote: > >> > >> Le 07/09/2018 à 16:36, Xavier a écrit : > >>> Le 07/09/2018 à 13:38, Bastien ROUCARIES a écrit : > On Thu, Sep 6, 2018 at 9:45 PM Thorsten Alteholz > wrote: > > > > Hi Bastien, > > > > On Wed, 5 Sep 2018, Bastien ROUCARIES wrote: > >>> - put together packages that belong together; I am not sure here, > >>> but > >>> wouldn't it be fine to have just one package node-d3 or node-babel > >>> that contains all corresponding modules (though their different > >>> versions > >>> might create problems in keeping track of them)? > >> > >> I strongly oppose to keep different version.# > > > > I don't meant to have different versions of one package here, but > > bundling several packages with different versions, so that it might not > > be > > clear what version the resulting package might get. > > I agree with this maybe we could get something like: > mainpackage+embded-nameembded1-version+embded-namembdedversion2-version+version > ? > > Bastien > >>> > >>> Hello, > >>> > >>> I've written a little draft: > >>> https://wiki.debian.org/Javascript/GroupedSourcePackageProxy > >> > >> I've updated draft to build a stateless proxy: DB was a bad idea since > >> it can be modified at each request. > >> I started to build groupedsources.cgi. The function to build grouped > >> upstream sources works. Now I'm going to write the download part. When > >> ready, you will be able to test with node-tap, simply by changing > >> debian/watch. > > > > No I will not use as is. Actually node-tap use upstream tar ball > > renamed as per dpkg spec [1]. > > > > You solution use a repack... > > > > > > uscan support multiple tar (in V4) but only with one version. Your > > redirector could help by fixing the version problem. > > OK, my redirector is ready. It provides all component with the same > version. Example of debian/watch: > > # Main > https://qa.debian.org/cgi-bin/groupedsources.cgi?upstream=npmjs/nodedbi+nmpjs/own-or > \ > .*=mainUpstream-(\d.*)\.(?:tgz|tar\.(?:gz|bz2|xz)) > # Component own-or > opts=component=own-or \ > https://qa.debian.org/cgi-bin/groupedsources.cgi?upstream=npmjs/nodedbi+nmpjs/own-or=own-or; > \ > .*=mainUpstream-(\d.*)\.(?:tgz|tar\.(?:gz|bz2|xz)) > ... > > Downloads are redirected to npmjs and not built by groupedsources.cgi > > > A minor point about version, it should be + instead of ~. Embded > > version are after normal version. I think the best will be to use +~ > > to separate embed version. It is unlikey someone will use +~ and it is > > a perfectly legal string. > > > > so I will recommend as version > > mainversion+dsembded+~version1+~version2+~version3 > > OK, to simplify version, the second part is a cumulative version (sum of > digits of each component). Example: 1.2.3+~6.2.4 > There is a "over" parameter in CGI to increase first digit (in case it > was decreased due to the removal of 1 component) I prefer the previous version of version string. Sorry no sum please. Be stupid. > >> If this proposition is acceptable, I'll propose a policy patch to > >> authorize JS grouped sources and a JS policy patch for details. > > > > [1] > > https://raphaelhertzog.com/2010/09/07/how-to-use-multiple-upstream-tarballs-in-debian-source-packages/ > > > > > >> > >> Cheers, > >> Xavier -- Pkg-javascript-devel mailing list Pkg-javascript-devel@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel
Re: [Pkg-javascript-devel] node packages in NEW
Le 09/09/2018 à 23:36, Bastien ROUCARIES a écrit : > On Sat, Sep 8, 2018 at 6:17 PM Xavier wrote: >> >> Le 07/09/2018 à 16:36, Xavier a écrit : >>> Le 07/09/2018 à 13:38, Bastien ROUCARIES a écrit : On Thu, Sep 6, 2018 at 9:45 PM Thorsten Alteholz wrote: > > Hi Bastien, > > On Wed, 5 Sep 2018, Bastien ROUCARIES wrote: >>> - put together packages that belong together; I am not sure here, but >>> wouldn't it be fine to have just one package node-d3 or node-babel >>> that contains all corresponding modules (though their different >>> versions >>> might create problems in keeping track of them)? >> >> I strongly oppose to keep different version.# > > I don't meant to have different versions of one package here, but > bundling several packages with different versions, so that it might not be > clear what version the resulting package might get. I agree with this maybe we could get something like: mainpackage+embded-nameembded1-version+embded-namembdedversion2-version+version ? Bastien >>> >>> Hello, >>> >>> I've written a little draft: >>> https://wiki.debian.org/Javascript/GroupedSourcePackageProxy >> >> I've updated draft to build a stateless proxy: DB was a bad idea since >> it can be modified at each request. >> I started to build groupedsources.cgi. The function to build grouped >> upstream sources works. Now I'm going to write the download part. When >> ready, you will be able to test with node-tap, simply by changing >> debian/watch. > > No I will not use as is. Actually node-tap use upstream tar ball > renamed as per dpkg spec [1]. > > You solution use a repack... > > > uscan support multiple tar (in V4) but only with one version. Your > redirector could help by fixing the version problem. OK, my redirector is ready. It provides all component with the same version. Example of debian/watch: # Main https://qa.debian.org/cgi-bin/groupedsources.cgi?upstream=npmjs/nodedbi+nmpjs/own-or \ .*=mainUpstream-(\d.*)\.(?:tgz|tar\.(?:gz|bz2|xz)) # Component own-or opts=component=own-or \ https://qa.debian.org/cgi-bin/groupedsources.cgi?upstream=npmjs/nodedbi+nmpjs/own-or=own-or; \ .*=mainUpstream-(\d.*)\.(?:tgz|tar\.(?:gz|bz2|xz)) ... Downloads are redirected to npmjs and not built by groupedsources.cgi > A minor point about version, it should be + instead of ~. Embded > version are after normal version. I think the best will be to use +~ > to separate embed version. It is unlikey someone will use +~ and it is > a perfectly legal string. > > so I will recommend as version > mainversion+dsembded+~version1+~version2+~version3 OK, to simplify version, the second part is a cumulative version (sum of digits of each component). Example: 1.2.3+~6.2.4 There is a "over" parameter in CGI to increase first digit (in case it was decreased due to the removal of 1 component) >> If this proposition is acceptable, I'll propose a policy patch to >> authorize JS grouped sources and a JS policy patch for details. > > [1] > https://raphaelhertzog.com/2010/09/07/how-to-use-multiple-upstream-tarballs-in-debian-source-packages/ > > >> >> Cheers, >> Xavier -- Pkg-javascript-devel mailing list Pkg-javascript-devel@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel
Re: [Pkg-javascript-devel] node packages in NEW
On Sat, Sep 8, 2018 at 6:17 PM Xavier wrote: > > Le 07/09/2018 à 16:36, Xavier a écrit : > > Le 07/09/2018 à 13:38, Bastien ROUCARIES a écrit : > >> On Thu, Sep 6, 2018 at 9:45 PM Thorsten Alteholz > >> wrote: > >>> > >>> Hi Bastien, > >>> > >>> On Wed, 5 Sep 2018, Bastien ROUCARIES wrote: > > - put together packages that belong together; I am not sure here, but > > wouldn't it be fine to have just one package node-d3 or node-babel > > that contains all corresponding modules (though their different > > versions > > might create problems in keeping track of them)? > > I strongly oppose to keep different version.# > >>> > >>> I don't meant to have different versions of one package here, but > >>> bundling several packages with different versions, so that it might not be > >>> clear what version the resulting package might get. > >> > >> I agree with this maybe we could get something like: > >> mainpackage+embded-nameembded1-version+embded-namembdedversion2-version+version > >> ? > >> > >> Bastien > > > > Hello, > > > > I've written a little draft: > > https://wiki.debian.org/Javascript/GroupedSourcePackageProxy > > I've updated draft to build a stateless proxy: DB was a bad idea since > it can be modified at each request. > I started to build groupedsources.cgi. The function to build grouped > upstream sources works. Now I'm going to write the download part. When > ready, you will be able to test with node-tap, simply by changing > debian/watch. No I will not use as is. Actually node-tap use upstream tar ball renamed as per dpkg spec [1]. You solution use a repack... uscan support multiple tar (in V4) but only with one version. Your redirector could help by fixing the version problem. A minor point about version, it should be + instead of ~. Embded version are after normal version. I think the best will be to use +~ to separate embed version. It is unlikey someone will use +~ and it is a perfectly legal string. so I will recommend as version mainversion+dsembded+~version1+~version2+~version3 > > If this proposition is acceptable, I'll propose a policy patch to > authorize JS grouped sources and a JS policy patch for details. [1] https://raphaelhertzog.com/2010/09/07/how-to-use-multiple-upstream-tarballs-in-debian-source-packages/ > > Cheers, > Xavier -- Pkg-javascript-devel mailing list Pkg-javascript-devel@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel
Re: [Pkg-javascript-devel] node packages in NEW
Le 07/09/2018 à 16:36, Xavier a écrit : > Le 07/09/2018 à 13:38, Bastien ROUCARIES a écrit : >> On Thu, Sep 6, 2018 at 9:45 PM Thorsten Alteholz wrote: >>> >>> Hi Bastien, >>> >>> On Wed, 5 Sep 2018, Bastien ROUCARIES wrote: > - put together packages that belong together; I am not sure here, but > wouldn't it be fine to have just one package node-d3 or node-babel > that contains all corresponding modules (though their different > versions > might create problems in keeping track of them)? I strongly oppose to keep different version.# >>> >>> I don't meant to have different versions of one package here, but >>> bundling several packages with different versions, so that it might not be >>> clear what version the resulting package might get. >> >> I agree with this maybe we could get something like: >> mainpackage+embded-nameembded1-version+embded-namembdedversion2-version+version >> ? >> >> Bastien > > Hello, > > I've written a little draft: > https://wiki.debian.org/Javascript/GroupedSourcePackageProxy I've updated draft to build a stateless proxy: DB was a bad idea since it can be modified at each request. I started to build groupedsources.cgi. The function to build grouped upstream sources works. Now I'm going to write the download part. When ready, you will be able to test with node-tap, simply by changing debian/watch. If this proposition is acceptable, I'll propose a policy patch to authorize JS grouped sources and a JS policy patch for details. Cheers, Xavier -- Pkg-javascript-devel mailing list Pkg-javascript-devel@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel
Re: [Pkg-javascript-devel] node packages in NEW
Le 07/09/2018 à 13:38, Bastien ROUCARIES a écrit : > On Thu, Sep 6, 2018 at 9:45 PM Thorsten Alteholz wrote: >> >> Hi Bastien, >> >> On Wed, 5 Sep 2018, Bastien ROUCARIES wrote: - put together packages that belong together; I am not sure here, but wouldn't it be fine to have just one package node-d3 or node-babel that contains all corresponding modules (though their different versions might create problems in keeping track of them)? >>> >>> I strongly oppose to keep different version.# >> >> I don't meant to have different versions of one package here, but >> bundling several packages with different versions, so that it might not be >> clear what version the resulting package might get. > > I agree with this maybe we could get something like: > mainpackage+embded-nameembded1-version+embded-namembdedversion2-version+version > ? > > Bastien Hello, I've written a little draft: https://wiki.debian.org/Javascript/GroupedSourcePackageProxy Cheers, Xavier -- Pkg-javascript-devel mailing list Pkg-javascript-devel@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel
Re: [Pkg-javascript-devel] node packages in NEW
On Thu, Sep 6, 2018 at 9:45 PM Thorsten Alteholz wrote: > > Hi Bastien, > > On Wed, 5 Sep 2018, Bastien ROUCARIES wrote: > >> - put together packages that belong together; I am not sure here, but > >> wouldn't it be fine to have just one package node-d3 or node-babel > >> that contains all corresponding modules (though their different > >> versions > >> might create problems in keeping track of them)? > > > > I strongly oppose to keep different version.# > > I don't meant to have different versions of one package here, but > bundling several packages with different versions, so that it might not be > clear what version the resulting package might get. I agree with this maybe we could get something like: mainpackage+embded-nameembded1-version+embded-namembdedversion2-version+version ? Bastien > >Thorsten > > > -- > Pkg-javascript-devel mailing list > Pkg-javascript-devel@alioth-lists.debian.net > https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel -- Pkg-javascript-devel mailing list Pkg-javascript-devel@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel
Re: [Pkg-javascript-devel] node packages in NEW
Hi, On Thu, 6 Sep 2018, Pirate Praveen wrote: I suggest we categorize the packages in NEW and process accordingly. I can help with categorizing it. I propose the following, 1. Simple modules that could be embedded - REJECT. 2. Modules that includes a build step, for example that needs babel, webpack etc. (Modules that will produce a source is missing lintian error). I think those packages would be better in their own package as it will make embedding more complicated to maintain - ACCEPT 3. A module that is a dependency or build dependency of more than 3 packages (arbitrary, could be 5 as well) - ACCEPT There should be no package from 1. in 3. One line of code (=exaggeration for simple module) should be always embedded independent of the number of packages that depend on it. Thorsten -- Pkg-javascript-devel mailing list Pkg-javascript-devel@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel
Re: [Pkg-javascript-devel] node packages in NEW
Hi Bastien, On Wed, 5 Sep 2018, Bastien ROUCARIES wrote: - put together packages that belong together; I am not sure here, but wouldn't it be fine to have just one package node-d3 or node-babel that contains all corresponding modules (though their different versions might create problems in keeping track of them)? I strongly oppose to keep different version.# I don't meant to have different versions of one package here, but bundling several packages with different versions, so that it might not be clear what version the resulting package might get. Thorsten -- Pkg-javascript-devel mailing list Pkg-javascript-devel@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel
Re: [Pkg-javascript-devel] node packages in NEW
On Thu, Sep 6, 2018 at 10:05 AM Xavier wrote: > > Le 05/09/2018 à 23:14, Bastien ROUCARIES a écrit : > > On Wed, Sep 5, 2018 at 11:08 PM Bastien ROUCARIES > > wrote: > >> > >> On Wed, Sep 5, 2018 at 10:50 PM Thorsten Alteholz > >> wrote: > >>> > >>> Hi everybody, > >>> > >>> as you already know, there is a big number of node packages waiting in > >>> NEW. Does Debian really need all those packages? > >>> > >>> node packages are rather small and often consist only of a few lines of > >>> code. From my point of view it is very unlikely that such packages will > >>> change over time, so their code will remain constant forever. More likely > >>> upstreams will add new features and pay no attention to backward > >>> compatible APIs. > >>> > >>> In the node ecosystem everything is fine. Their developers use carets or > >>> tildes as dependency operators and just depened on the version of the API > >>> they really need. > >>> > >>> In Debian such packages basically create two problems. They bloat the > >>> packages file, which prolongs the process of installing or updating > >>> packages. Further Debian only allows packages with one, the latest, > >>> version in the archive. So uploading packages with the newer API would > >>> make packages unusable, that still depend on the older API. Usually this > >>> is not recognized and suddenly packages in the archive won't work anymore. > >>> One could introduce versions within package names, but this would just > >>> multiply the number of node packages. > >>> > >>> To answer my question from above: no, nobody needs these small packages. > >>> > >>> But of course Debian wants to have packages with a certain functionality. > >>> Stuff like grunt, d3, babel and npm totally make sense to have. > >> > >> They are at least what are waiting to be packaging: > >> - browserify > >> - a few package that are needed to regenerate web fonts. > >>> > >>> So in order to reduce the number of node packages that appear in NEW and > >>> the archive one might lessen the Debian embedding policy. > >>> What do you think about embedding ... > >>> - small modules that are not going to be changed and contain less than > >>> 50 lines of code (this limit is totally arbitrary) > >>> - put together packages that belong together; I am not sure here, but > >>> wouldn't it be fine to have just one package node-d3 or node-babel > >>> that contains all corresponding modules (though their different > >>> versions > >>> might create problems in keeping track of them)? > >> > >> I strongly oppose to keep different version. > >>> In order to not lose track of the installed software, providing something > >>> like debian/modules.embedded might be nice to have? > >> > >> i have proposed to do something with uscan in order to simplify the > >> work but I need help on it. The goal is to do something like > >> ,node-bind that embed node-has. > >> > >> The main problem is really updating and getting newer version > >> automatically. > >> > >> With versioned provides we could even keep the best of the world (see > >> node-has or node-tap). > >> > >> Debhelper support will be nice but it is second order problem compared to > >> uscan. > > > > see #899073 for bugs > > Hello, > > instead of modifying uscan, we could perhaps build a "proxy" like > https://qa.debian.org/cgi-bin/fakeupstream.cgi which could populate > `node_modules/` directory. Example of such debian/watch: > > version=3 > opts="dversionmangle=s/\+embed\d*$//,repacksuffix=+embed" \ > > https://qa.debian.org/cgi-bin/embednpmjs.cgi?upstream=npmjs/package=npmjs/dependency1,npmjs/dependency2 > \ > .*=package-(\d.*)\.(?:tgz|tar\.(?:gz|bz2|xz)) > > This CGI could add node_modules/dependency1 and node_modules/dependency2 > in upstream archive. Do not add in node_modules but in subdirectory see multiple tar dpkg (like that I have done in node-tap) > Note that something may be found to verify gpg signatures if any. > > Cheers, > Xavier -- Pkg-javascript-devel mailing list Pkg-javascript-devel@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel
Re: [Pkg-javascript-devel] node packages in NEW
Le 06/09/2018 à 08:05, Pirate Praveen a écrit : > On 06/09/18 10:15 AM, Pirate Praveen wrote: >> I suggest we categorize the packages in NEW and process accordingly. I can >> help with categorizing it. >> >> I propose the following, >> >> 1. Simple modules that could be embedded - REJECT. >> 2. Modules that includes a build step, for example that needs babel, webpack >> etc. (Modules that will produce a source is missing lintian error). I think >> those packages would be better in their own package as it will make >> embedding more complicated to maintain - ACCEPT >> 3. A module that is a dependency or build dependency of more than 3 packages >> (arbitrary, could be 5 as well) - ACCEPT >> > > I have started this categorization here, > > https://wiki.debian.org/Javascript/Nodejs/NEW Hello, Thanks, I've updated this wiki page with my proposed packages: - 8 to reject/embed - 3 to keep - 2 to discuss Cheers, Xavier -- Pkg-javascript-devel mailing list Pkg-javascript-devel@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel
[Pkg-javascript-devel] node packages in NEW
Le 06/09/2018 à 08:05, Pirate Praveen a écrit : > On 06/09/18 10:15 AM, Pirate Praveen wrote: >> I suggest we categorize the packages in NEW and process accordingly. I can >> help with categorizing it. >> >> I propose the following, >> >> 1. Simple modules that could be embedded - REJECT. >> 2. Modules that includes a build step, for example that needs babel, webpack >> etc. (Modules that will produce a source is missing lintian error). I think >> those packages would be better in their own package as it will make >> embedding more complicated to maintain - ACCEPT >> 3. A module that is a dependency or build dependency of more than 3 packages >> (arbitrary, could be 5 as well) - ACCEPT >> > > I have started this categorization here, > > https://wiki.debian.org/Javascript/Nodejs/NEW (reposted with my debian address) Hello, Thanks, I've updated this wiki page with my proposed packages: - 8 to reject/embed - 3 to keep - 2 to discuss Cheers, Xavier -- Pkg-javascript-devel mailing list Pkg-javascript-devel@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel
Re: [Pkg-javascript-devel] node packages in NEW
On 06/09/18 10:15 AM, Pirate Praveen wrote: > I suggest we categorize the packages in NEW and process accordingly. I can > help with categorizing it. > > I propose the following, > > 1. Simple modules that could be embedded - REJECT. > 2. Modules that includes a build step, for example that needs babel, webpack > etc. (Modules that will produce a source is missing lintian error). I think > those packages would be better in their own package as it will make embedding > more complicated to maintain - ACCEPT > 3. A module that is a dependency or build dependency of more than 3 packages > (arbitrary, could be 5 as well) - ACCEPT > I have started this categorization here, https://wiki.debian.org/Javascript/Nodejs/NEW signature.asc Description: OpenPGP digital signature -- Pkg-javascript-devel mailing list Pkg-javascript-devel@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel
Re: [Pkg-javascript-devel] node packages in NEW
n Wed, Sep 5, 2018 at 11:29 PM Jérémy Lal wrote: > > > > 2018-09-05 23:14 GMT+02:00 Bastien ROUCARIES : >> >> On Wed, Sep 5, 2018 at 11:08 PM Bastien ROUCARIES >> wrote: >> > >> > On Wed, Sep 5, 2018 at 10:50 PM Thorsten Alteholz >> > wrote: >> >> > > In order to not lose track of the installed software, providing something >> > > like debian/modules.embedded might be nice to have? >> > >> > i have proposed to do something with uscan in order to simplify the >> > work but I need help on it. The goal is to do something like >> > ,node-bind that embed node-has. >> > >> > The main problem is really updating and getting newer version >> > automatically. > > > There is pkg-components, see node-tar package, a tentative to use it to embed > some node_modules. > It's somewhat doing the job, though not easy to use. I have done manually for node-tap for instance. The problem is really uscan support not debhelper. Pkg-component is nice but does not solve uscan problem > > Jérémy > -- Pkg-javascript-devel mailing list Pkg-javascript-devel@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel
Re: [Pkg-javascript-devel] node packages in NEW
2018-09-05 23:14 GMT+02:00 Bastien ROUCARIES : > On Wed, Sep 5, 2018 at 11:08 PM Bastien ROUCARIES > wrote: > > > > On Wed, Sep 5, 2018 at 10:50 PM Thorsten Alteholz > wrote: > > > > In order to not lose track of the installed software, providing > something > > > like debian/modules.embedded might be nice to have? > > > > i have proposed to do something with uscan in order to simplify the > > work but I need help on it. The goal is to do something like > > ,node-bind that embed node-has. > > > > The main problem is really updating and getting newer version > automatically. > There is pkg-components, see node-tar package, a tentative to use it to embed some node_modules. It's somewhat doing the job, though not easy to use. Jérémy -- Pkg-javascript-devel mailing list Pkg-javascript-devel@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel
Re: [Pkg-javascript-devel] node packages in NEW
On Wed, Sep 5, 2018 at 11:08 PM Bastien ROUCARIES wrote: > > On Wed, Sep 5, 2018 at 10:50 PM Thorsten Alteholz wrote: > > > > Hi everybody, > > > > as you already know, there is a big number of node packages waiting in > > NEW. Does Debian really need all those packages? > > > > node packages are rather small and often consist only of a few lines of > > code. From my point of view it is very unlikely that such packages will > > change over time, so their code will remain constant forever. More likely > > upstreams will add new features and pay no attention to backward > > compatible APIs. > > > > In the node ecosystem everything is fine. Their developers use carets or > > tildes as dependency operators and just depened on the version of the API > > they really need. > > > > In Debian such packages basically create two problems. They bloat the > > packages file, which prolongs the process of installing or updating > > packages. Further Debian only allows packages with one, the latest, > > version in the archive. So uploading packages with the newer API would > > make packages unusable, that still depend on the older API. Usually this > > is not recognized and suddenly packages in the archive won't work anymore. > > One could introduce versions within package names, but this would just > > multiply the number of node packages. > > > > To answer my question from above: no, nobody needs these small packages. > > > > But of course Debian wants to have packages with a certain functionality. > > Stuff like grunt, d3, babel and npm totally make sense to have. > > They are at least what are waiting to be packaging: > - browserify > - a few package that are needed to regenerate web fonts. > > > > So in order to reduce the number of node packages that appear in NEW and > > the archive one might lessen the Debian embedding policy. > > What do you think about embedding ... > > - small modules that are not going to be changed and contain less than > > 50 lines of code (this limit is totally arbitrary) > > - put together packages that belong together; I am not sure here, but > > wouldn't it be fine to have just one package node-d3 or node-babel > > that contains all corresponding modules (though their different versions > > might create problems in keeping track of them)? > > I strongly oppose to keep different version. > > In order to not lose track of the installed software, providing something > > like debian/modules.embedded might be nice to have? > > i have proposed to do something with uscan in order to simplify the > work but I need help on it. The goal is to do something like > ,node-bind that embed node-has. > > The main problem is really updating and getting newer version automatically. > > With versioned provides we could even keep the best of the world (see > node-has or node-tap). > > Debhelper support will be nice but it is second order problem compared to > uscan. see #899073 for bugs > > > > As you know your tools best, can you please create a proposal of how you > > would like to handle maintenance in such a new situation? > > > > Maybe we can already start by removing node-is-generator-fn, node-is-npm, > > node-is-unc-path and node-isstream and create a wiki page to keep track of > > all node modules that are candidates of being embedded? > > Maybe, but in the same time could we get speedy review of dependency > of browserify ? > > > > Though I admit it might be a bit demotivating, we would like to REJECT all > > node packages currently in NEW and start as soon as possible with the new > > policy. > > > >Thorsten, on behalf of the ftpmasters > > > > > > -- > > Pkg-javascript-devel mailing list > > Pkg-javascript-devel@alioth-lists.debian.net > > https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel -- Pkg-javascript-devel mailing list Pkg-javascript-devel@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel
Re: [Pkg-javascript-devel] node packages in NEW
On Wed, Sep 5, 2018 at 10:50 PM Thorsten Alteholz wrote: > > Hi everybody, > > as you already know, there is a big number of node packages waiting in > NEW. Does Debian really need all those packages? > > node packages are rather small and often consist only of a few lines of > code. From my point of view it is very unlikely that such packages will > change over time, so their code will remain constant forever. More likely > upstreams will add new features and pay no attention to backward > compatible APIs. > > In the node ecosystem everything is fine. Their developers use carets or > tildes as dependency operators and just depened on the version of the API > they really need. > > In Debian such packages basically create two problems. They bloat the > packages file, which prolongs the process of installing or updating > packages. Further Debian only allows packages with one, the latest, > version in the archive. So uploading packages with the newer API would > make packages unusable, that still depend on the older API. Usually this > is not recognized and suddenly packages in the archive won't work anymore. > One could introduce versions within package names, but this would just > multiply the number of node packages. > > To answer my question from above: no, nobody needs these small packages. > > But of course Debian wants to have packages with a certain functionality. > Stuff like grunt, d3, babel and npm totally make sense to have. They are at least what are waiting to be packaging: - browserify - a few package that are needed to regenerate web fonts. > > So in order to reduce the number of node packages that appear in NEW and > the archive one might lessen the Debian embedding policy. > What do you think about embedding ... > - small modules that are not going to be changed and contain less than > 50 lines of code (this limit is totally arbitrary) > - put together packages that belong together; I am not sure here, but > wouldn't it be fine to have just one package node-d3 or node-babel > that contains all corresponding modules (though their different versions > might create problems in keeping track of them)? I strongly oppose to keep different version. > In order to not lose track of the installed software, providing something > like debian/modules.embedded might be nice to have? i have proposed to do something with uscan in order to simplify the work but I need help on it. The goal is to do something like ,node-bind that embed node-has. The main problem is really updating and getting newer version automatically. With versioned provides we could even keep the best of the world (see node-has or node-tap). Debhelper support will be nice but it is second order problem compared to uscan. > > As you know your tools best, can you please create a proposal of how you > would like to handle maintenance in such a new situation? > > Maybe we can already start by removing node-is-generator-fn, node-is-npm, > node-is-unc-path and node-isstream and create a wiki page to keep track of > all node modules that are candidates of being embedded? Maybe, but in the same time could we get speedy review of dependency of browserify ? > > Though I admit it might be a bit demotivating, we would like to REJECT all > node packages currently in NEW and start as soon as possible with the new > policy. > >Thorsten, on behalf of the ftpmasters > > > -- > Pkg-javascript-devel mailing list > Pkg-javascript-devel@alioth-lists.debian.net > https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel -- Pkg-javascript-devel mailing list Pkg-javascript-devel@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel
Re: [Pkg-javascript-devel] node packages in NEW
Le 05/09/2018 à 22:58, Xavier a écrit : > Le 05/09/2018 à 22:45, Thorsten Alteholz a écrit : >> Hi everybody, >> >> as you already know, there is a big number of node packages waiting in >> NEW. Does Debian really need all those packages? >> >> node packages are rather small and often consist only of a few lines of >> code. From my point of view it is very unlikely that such packages will >> change over time, so their code will remain constant forever. More >> likely upstreams will add new features and pay no attention to backward >> compatible APIs. >> >> In the node ecosystem everything is fine. Their developers use carets or >> tildes as dependency operators and just depened on the version of the >> API they really need. >> >> In Debian such packages basically create two problems. They bloat the >> packages file, which prolongs the process of installing or updating >> packages. Further Debian only allows packages with one, the latest, >> version in the archive. So uploading packages with the newer API would >> make packages unusable, that still depend on the older API. Usually this >> is not recognized and suddenly packages in the archive won't work >> anymore. One could introduce versions within package names, but this >> would just multiply the number of node packages. >> >> To answer my question from above: no, nobody needs these small packages. >> >> But of course Debian wants to have packages with a certain >> functionality. Stuff like grunt, d3, babel and npm totally make sense to >> have. >> >> So in order to reduce the number of node packages that appear in NEW and >> the archive one might lessen the Debian embedding policy. >> What do you think about embedding ... >> - small modules that are not going to be changed and contain less than >> 50 lines of code (this limit is totally arbitrary) >> - put together packages that belong together; I am not sure here, but >> wouldn't it be fine to have just one package node-d3 or node-babel >> that contains all corresponding modules (though their different versions >> might create problems in keeping track of them)? >> In order to not lose track of the installed software, providing >> something like debian/modules.embedded might be nice to have? >> >> As you know your tools best, can you please create a proposal of how you >> would like to handle maintenance in such a new situation? >> >> Maybe we can already start by removing node-is-generator-fn, >> node-is-npm, node-is-unc-path and node-isstream and create a wiki page >> to keep track of all node modules that are candidates of being embedded? >> >> Though I admit it might be a bit demotivating, we would like to REJECT >> all node packages currently in NEW and start as soon as possible with >> the new policy. >> >> Thorsten, on behalf of the ftpmasters > > Hello, > > you're right even if it may conflict a little with > https://wiki.debian.org/EmbeddedCodeCopies > > We could also have a different policy for: > - dependency of a end-user software > - development libraries not yet used by any end-user software in main > > In the first case, could follow normal process, and your proposition > could be applied for the second > > Cheers, > Xavier - More secured for first case (no copy and more easy to follow CVE) - Libraries in the 2nd case: perhaps insert in ITP issue the use level (NPM weekly downloads for example) and/or any other justification (important framework like vue.js,...) -- Pkg-javascript-devel mailing list Pkg-javascript-devel@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel
Re: [Pkg-javascript-devel] node packages in NEW
Le 05/09/2018 à 22:45, Thorsten Alteholz a écrit : > Hi everybody, > > as you already know, there is a big number of node packages waiting in > NEW. Does Debian really need all those packages? > > node packages are rather small and often consist only of a few lines of > code. From my point of view it is very unlikely that such packages will > change over time, so their code will remain constant forever. More > likely upstreams will add new features and pay no attention to backward > compatible APIs. > > In the node ecosystem everything is fine. Their developers use carets or > tildes as dependency operators and just depened on the version of the > API they really need. > > In Debian such packages basically create two problems. They bloat the > packages file, which prolongs the process of installing or updating > packages. Further Debian only allows packages with one, the latest, > version in the archive. So uploading packages with the newer API would > make packages unusable, that still depend on the older API. Usually this > is not recognized and suddenly packages in the archive won't work > anymore. One could introduce versions within package names, but this > would just multiply the number of node packages. > > To answer my question from above: no, nobody needs these small packages. > > But of course Debian wants to have packages with a certain > functionality. Stuff like grunt, d3, babel and npm totally make sense to > have. > > So in order to reduce the number of node packages that appear in NEW and > the archive one might lessen the Debian embedding policy. > What do you think about embedding ... > - small modules that are not going to be changed and contain less than > 50 lines of code (this limit is totally arbitrary) > - put together packages that belong together; I am not sure here, but > wouldn't it be fine to have just one package node-d3 or node-babel > that contains all corresponding modules (though their different versions > might create problems in keeping track of them)? > In order to not lose track of the installed software, providing > something like debian/modules.embedded might be nice to have? > > As you know your tools best, can you please create a proposal of how you > would like to handle maintenance in such a new situation? > > Maybe we can already start by removing node-is-generator-fn, > node-is-npm, node-is-unc-path and node-isstream and create a wiki page > to keep track of all node modules that are candidates of being embedded? > > Though I admit it might be a bit demotivating, we would like to REJECT > all node packages currently in NEW and start as soon as possible with > the new policy. > > Thorsten, on behalf of the ftpmasters Hello, you're right even if it may conflict a little with https://wiki.debian.org/EmbeddedCodeCopies We could also have a different policy for: - dependency of a end-user software - development libraries not yet used by any end-user software in main In the first case, could follow normal process, and your proposition could be applied for the second Cheers, Xavier -- Pkg-javascript-devel mailing list Pkg-javascript-devel@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel
[Pkg-javascript-devel] node packages in NEW
Hi everybody, as you already know, there is a big number of node packages waiting in NEW. Does Debian really need all those packages? node packages are rather small and often consist only of a few lines of code. From my point of view it is very unlikely that such packages will change over time, so their code will remain constant forever. More likely upstreams will add new features and pay no attention to backward compatible APIs. In the node ecosystem everything is fine. Their developers use carets or tildes as dependency operators and just depened on the version of the API they really need. In Debian such packages basically create two problems. They bloat the packages file, which prolongs the process of installing or updating packages. Further Debian only allows packages with one, the latest, version in the archive. So uploading packages with the newer API would make packages unusable, that still depend on the older API. Usually this is not recognized and suddenly packages in the archive won't work anymore. One could introduce versions within package names, but this would just multiply the number of node packages. To answer my question from above: no, nobody needs these small packages. But of course Debian wants to have packages with a certain functionality. Stuff like grunt, d3, babel and npm totally make sense to have. So in order to reduce the number of node packages that appear in NEW and the archive one might lessen the Debian embedding policy. What do you think about embedding ... - small modules that are not going to be changed and contain less than 50 lines of code (this limit is totally arbitrary) - put together packages that belong together; I am not sure here, but wouldn't it be fine to have just one package node-d3 or node-babel that contains all corresponding modules (though their different versions might create problems in keeping track of them)? In order to not lose track of the installed software, providing something like debian/modules.embedded might be nice to have? As you know your tools best, can you please create a proposal of how you would like to handle maintenance in such a new situation? Maybe we can already start by removing node-is-generator-fn, node-is-npm, node-is-unc-path and node-isstream and create a wiki page to keep track of all node modules that are candidates of being embedded? Though I admit it might be a bit demotivating, we would like to REJECT all node packages currently in NEW and start as soon as possible with the new policy. Thorsten, on behalf of the ftpmasters -- Pkg-javascript-devel mailing list Pkg-javascript-devel@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel
