Bug#976331: [Pkg-javascript-devel] Bug#976331: [JS Policy] what to set in "Provides" field ?
Quoting Xavier (2020-12-06 07:59:25) > Le 06/12/2020 à 02:14, Jonas Smedegaard a écrit : > > Quoting Xavier (2020-12-03 21:19:48) > >> Le 03/12/2020 à 19:17, Jonas Smedegaard a écrit : > >>> This bug 976331 is *not* about repackaging embedded modules as > >>> separate *source* packages, but only about exposing embedded > >>> modules as *binary* packages - either virtual or real ones. > >> > >> That's part of what I misunderstood. So OK to do this here (after > >> ftpmaster rejection since you pushed node-serialize-javascript). > >> > >> But: I was able to upload a lot of packages this year because I > >> automatized many things. So splitting all mixed packages means > >> manually regenerating debian/control, debian/rules, > >> debian/*.install,... This means less uploads, more obsolescence and > >> then less security (and also less interest in doing such manual > >> stuff). > > > > Great that you develop tools to maintain packages more efficiently > > and more automated. If done in compliance with Debian Policy, that > > is. > > > > Do you say that it is not possible to automate packaging with > > embedded modules provided as virtual or real packages? Why do you > > think you can only develop efficient automating routines with hidden > > modules? > > Pkg-js-tools already automates virtual package. Ok, so you are saying that current automation _is_ effective for virtual binary packages but handling _real_ binary packages need manual work. > > ftpmaster wants to avoid too tiny source packages, but ftpmaster > > does not want duplicate code. > > No you're wrong here, they accepted a lot of embedded copies for JS > (see Jquery for example), not for C. > > Also they don't want too many little binary packages (not only > source). Sorry, I was unclear. Let me try rephrase to clarify: ftpmaster strongly dislikes (i.e. they will reject) too tiny source packages, but ftpmaster does not actively encourage (even if they might tolerate) duplicate code. My point was not that ftpmaster rejects duplicate code (they might in severe cases, but that is not really their task to judge on). My point was, instead, that it is wrong to interpret the fact that ftpmaster rejects tiny source packages as an endorsement of duplicate source through _repeated_ embedding of same module. It is not the task of ftpmaster to check _all_ Policy Violations - and even if it was then a package not rejected is not a proof that the package is optimally aligned with Debian Policy. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Bug#976331: [Pkg-javascript-devel] Bug#976331: [JS Policy] what to set in "Provides" field ?
Quoting Xavier (2020-12-03 17:33:18) > I'm not in favor of your proposal: if I need a node-very-few-module > which is provided by a package with many dependencies, I'm not happy > to depend on it. I don't recognize the above as being something I proposed (and I am not really sure what it says). Maybe there is a misunderstanding somewhere, and we do not really disagree as much? Please, let's try make sure we at least agree what we disagree on :-) I do _not_ blame you on linguistic failures here, Xavier - it might _seem_ like I am better at english than you but I might very well be worse than you in explaining myself and understaning what you write... - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Bug#976331: [Pkg-javascript-devel] Bug#976331: [JS Policy] what to set in "Provides" field ?
Le 03/12/2020 à 18:21, Jonas Smedegaard a écrit :
> Quoting Xavier (2020-12-03 17:33:18)
>> Le 03/12/2020 à 16:36, Jonas Smedegaard a écrit :
>>> Quoting Xavier (2020-12-03 15:44:48)
Le 03/12/2020 à 15:12, Jonas Smedegaard a écrit :
> Quoting Xavier (2020-12-03 14:35:25)
>> Le 03/12/2020 à 14:24, Xavier a écrit :
>>> Le 03/12/2020 à 12:44, Jonas Smedegaard a écrit :
These source packages embed nodejs module serialize-javascript
without offering it as virtual binary package:
node-compression-webpack-plugin
node-copy-webpack-plugin
node-uglifyjs-webpack-plugin
Please embed in only one source package provided as versioned
virtual package, and drop in other source packages instead
depending on the virtual package.
Severity raised since the lack of virtual package blocks upgrading
node-terser.
>
> [...]
>
>>> for now, dh-sequence-nodejs adds a "Provides" item for modules
>>> installed in root nodejs directories. Do we want to declare a
>>> "node-foo" for submodules (installed in a /node_modules
>>> directory) ?
>
> Whatever that tool does, the resulting package should declare
> Provides: for each embedded Nodejs module, properly versioned with
> the module's own version as first segment then "~" then source
> package version.
>
> I cannot see a reason for *any* embedded Nodejs module to stay
> hidden, but if someone comes up with some exceptional cases for
> that, then the reasoning should be explicitly documented in either
> README.source or README.Debian (and possibly in long description
> too).
I chose that because such modules are not directly usable using a
`require("foo")`, but I can change
>>>
>>> I am less interested in why historically some pattern was chosen.
>>>
>>> My interest is in what pattern to use going forward.
>>>
>>> Code in package have dependencies on code in other packages.
>>>
>>> We need to be able to declare dependencies between pieces of code.
>>>
>>> For JavaScript, code is grouped as "Nodejs modules".
>>>
>>> A a concrete example, Nodejs module rollup-plugin-terser depends on
>>> Nodejs module serialize-javascript.
>>>
>>> Going forward (regardless of why historically some other pattern was
>>> chosen), Debian package node-rollup-plugin-terser needs to be able to
>>> express a build-dependency on Debian package providing the Nodejs module
>>> serialize-javascript.
>>>
>>>
>> Note that the future lintian database (classification tags) will
>> permit to see node modules everywhere.
>
> Everywhere?
Sorry, I miss some explanations: lintian parses all files and emit a tag
each time it finds a node_module/foo/package.json or
/foo/package.json or >>> able to see nodejs embedded module in all Debian packages.
>>>
>>> Lintian can help check if a package is valid.
>>>
>>> Lintian cannot make a package declare as virtual Debian packages the
>>> Nodejs modules it has embedded.
>>>
>>>
NB2, you can also take a look at
https://lintian.debian.org/tags/nodejs-module-not-declared.html : it
shows node module installed in nodejs main dirs (not in node_modules/
for now).
>>>
>>> A web page (generated by lintian or written any other way) cannot make a
>>> package declare as virtual Debian packages the Nodejs modules it has
>>> embedded.
>>>
>>>
If we decide to change this ~policy, nodejs-module-not-declared should
also be updated.
>>>
>>> I am pretty sure that hiding generally usable embedded code violates a
>>> "should" somewhere in Debian Policy.
>>
>> If so, lintian should reports "error", not info/warning when a JS lib is
>> embedded. Ftpmasters didn't reject such packages (see jquery copies for
>> example).
>
> Ideally lintian should identify and report all errors.
>
> Ideally all packaging work could be automated.
>
> Reality is slightly different. though.
>
>
>
>>> Therefore, if Debian JavaScript Policy says that generally useful
>>> modules should be *hidden* instead of provided as virtual packages, then
>>> I consider Debian JavaScript Policy broken.
>>>
But in this case, we will have some not-directly-usable node-* virtual
packages.
>>>
>>> Why not-directly-usable?
>>>
>>> Obviously we should not _only_ declare "Provides:" but also make sure
>>> that the code is actually placed in the correct location below
>>> /usr/share/nodejs and check testsuite and establish autopkgtest and all
>>> the other things that is required for packaging code.
>>>
>>> Embedded code is not magically excluded from getting properly packaged.
>>
>> You're free to think that my packages are not properly packaged.
>
> I am not targeting you, nor am I targeting dh-sequence-nodejs, nor am I
> targeting lintian, nor am I targeting JavaScript Team Policy. You
> brought those up in this
Bug#976331: [Pkg-javascript-devel] Bug#976331: [JS Policy] what to set in "Provides" field ?
Quoting Xavier (2020-12-03 17:33:18)
> Le 03/12/2020 à 16:36, Jonas Smedegaard a écrit :
> > Quoting Xavier (2020-12-03 15:44:48)
> >> Le 03/12/2020 à 15:12, Jonas Smedegaard a écrit :
> >>> Quoting Xavier (2020-12-03 14:35:25)
> Le 03/12/2020 à 14:24, Xavier a écrit :
> > Le 03/12/2020 à 12:44, Jonas Smedegaard a écrit :
> >> These source packages embed nodejs module serialize-javascript
> >> without offering it as virtual binary package:
> >>
> >> node-compression-webpack-plugin
> >> node-copy-webpack-plugin
> >> node-uglifyjs-webpack-plugin
> >>
> >> Please embed in only one source package provided as versioned
> >> virtual package, and drop in other source packages instead
> >> depending on the virtual package.
> >>
> >> Severity raised since the lack of virtual package blocks upgrading
> >> node-terser.
> >>>
> >>> [...]
> >>>
> > for now, dh-sequence-nodejs adds a "Provides" item for modules
> > installed in root nodejs directories. Do we want to declare a
> > "node-foo" for submodules (installed in a /node_modules
> > directory) ?
> >>>
> >>> Whatever that tool does, the resulting package should declare
> >>> Provides: for each embedded Nodejs module, properly versioned with
> >>> the module's own version as first segment then "~" then source
> >>> package version.
> >>>
> >>> I cannot see a reason for *any* embedded Nodejs module to stay
> >>> hidden, but if someone comes up with some exceptional cases for
> >>> that, then the reasoning should be explicitly documented in either
> >>> README.source or README.Debian (and possibly in long description
> >>> too).
> >>
> >> I chose that because such modules are not directly usable using a
> >> `require("foo")`, but I can change
> >
> > I am less interested in why historically some pattern was chosen.
> >
> > My interest is in what pattern to use going forward.
> >
> > Code in package have dependencies on code in other packages.
> >
> > We need to be able to declare dependencies between pieces of code.
> >
> > For JavaScript, code is grouped as "Nodejs modules".
> >
> > A a concrete example, Nodejs module rollup-plugin-terser depends on
> > Nodejs module serialize-javascript.
> >
> > Going forward (regardless of why historically some other pattern was
> > chosen), Debian package node-rollup-plugin-terser needs to be able to
> > express a build-dependency on Debian package providing the Nodejs module
> > serialize-javascript.
> >
> >
> Note that the future lintian database (classification tags) will
> permit to see node modules everywhere.
> >>>
> >>> Everywhere?
> >>
> >> Sorry, I miss some explanations: lintian parses all files and emit a tag
> >> each time it finds a node_module/foo/package.json or
> >> /foo/package.json or >> able to see nodejs embedded module in all Debian packages.
> >
> > Lintian can help check if a package is valid.
> >
> > Lintian cannot make a package declare as virtual Debian packages the
> > Nodejs modules it has embedded.
> >
> >
> >> NB2, you can also take a look at
> >> https://lintian.debian.org/tags/nodejs-module-not-declared.html : it
> >> shows node module installed in nodejs main dirs (not in node_modules/
> >> for now).
> >
> > A web page (generated by lintian or written any other way) cannot make a
> > package declare as virtual Debian packages the Nodejs modules it has
> > embedded.
> >
> >
> >> If we decide to change this ~policy, nodejs-module-not-declared should
> >> also be updated.
> >
> > I am pretty sure that hiding generally usable embedded code violates a
> > "should" somewhere in Debian Policy.
>
> If so, lintian should reports "error", not info/warning when a JS lib is
> embedded. Ftpmasters didn't reject such packages (see jquery copies for
> example).
Ideally lintian should identify and report all errors.
Ideally all packaging work could be automated.
Reality is slightly different. though.
> > Therefore, if Debian JavaScript Policy says that generally useful
> > modules should be *hidden* instead of provided as virtual packages, then
> > I consider Debian JavaScript Policy broken.
> >
> >> But in this case, we will have some not-directly-usable node-* virtual
> >> packages.
> >
> > Why not-directly-usable?
> >
> > Obviously we should not _only_ declare "Provides:" but also make sure
> > that the code is actually placed in the correct location below
> > /usr/share/nodejs and check testsuite and establish autopkgtest and all
> > the other things that is required for packaging code.
> >
> > Embedded code is not magically excluded from getting properly packaged.
>
> You're free to think that my packages are not properly packaged.
I am not targeting you, nor am I targeting dh-sequence-nodejs, nor am I
targeting lintian, nor am I targeting JavaScript Team Policy. You
brought those up in this _discussion_ about a package that I filed a
bugreport against.
Bug#976331: [Pkg-javascript-devel] Bug#976331: [JS Policy] what to set in "Provides" field ?
On 2020, ഡിസംബർ 3 10:03:18 PM IST, Xavier wrote: >I'm not in favor of your proposal: if I need a node-very-few-module >which is provided by a package with many dependencies, I'm not happy to >depend on it. To apply that, we should then choose with precaution in >which package we will embed each code. Packaging JS is already a hudge >work, I'm not sure we need more complexity. > >@JS-Team, does anyone have any other opinion? Else which option do you >choose? I'll update pkg-js-tools with your choice of course. I agree with yadd here. We should not complicate js packaging more than it already is. -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
