Quoting Xavier (2020-12-03 21:19:48)
> Le 03/12/2020 à 19:17, Jonas Smedegaard a écrit :
> > Quoting Xavier (2020-12-03 18:42:17)
> >> 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.
[,,,]
> > I am pretty sure that hiding generally usable embedded code
> > violates a "should" somewhere in Debian Policy.
Here (as also mentioned elsewhere in the email thread):
https://www.debian.org/doc/debian-policy/ch-source.html#embedded-code-copies
> >> If ftpmasters ask us to minimize package number by embedding
> >> to-little-modules and if then we decide to publish them as
> >> separated binary packages, I don't succeed to understand the
> >> benefit. Then we should return back to previous policy: one source
> >> = one package?
> >
> > My understanding is that ftpmasters dislike small *source* packages.
> >
> > Small source packages is a burden in *every* package tracking in
> > Debian.
> >
> > Small binary packages is also a burden in *some* package tracking.
> >
> > Zero-size binary packages is also a burden in *some* package
> > tracking, but I don't hear ftpmasters complain about task packages.
> >
> >
> > 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?
Here is a concrete example of a minimal (manual) that I propose to do
for one of the three packages involved in this bugreport (and then have
the other 2 packages drop the embedded module ans instead depend on the
now accessible-as-package-name module):
https://salsa.debian.org/js-team/node-cosmiconfig/-/commit/125869f9
I don't understand how that cannot be automated.
I do see how it requires coordination across packages, to decide which
one source package should contain the embedded module, instead of *all*
source packages containing *duplicate* modules - but that coordination
work is *necessary work, not optional. It is not ok to package the
Apache2 server with embedded zlib library, regardless if it is easier to
automate without unentangling things done too tight upstream. Nodejs is
no different from that!
ftpmaster wants to avoid too tiny source packages, but ftpmaster does
not want duplicate code.
- 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
