[Pkg-javascript-devel] [RFS] node-trust-json-document

Ayoyimika Ajibade ayoyimikaajibade at gmail.com
Fri Feb 25 08:16:17 GMT 2022


Hello!

I have taken into consideration the information and corrections and
here is the updated repo
https://salsa.debian.org/Ayoyimika/node-trust-json-document

Thanks and Cheers

On Sat, Feb 12, 2022 at 2:26 PM Jonas Smedegaard <jonas at jones.dk> wrote:
>
> [ adding back mailinglist as recipient ]
>
> Quoting Ayoyimika Ajibade (2022-02-12 07:00:54)
> > > update webpack command
> > As part of the migration to webpack5, some options are no more valid
> > example is the -d or -p option which was previously referred to set
> > the development or production environment respectively, hence the
> > change was the functional effect (e.g needed for webpack5), which will
> > try to make my commit messages more descriptive. Thanks for putting
> > that in.
>
> Ah, it is news to me that webpack5 does not support the short-form
> options.
>
> Related note: I run a few Debian systems - laptops and servers - and on
> all of them I install the package apt-listchanges, which shows package
> changes each time I run "apt update && apt update" - which I do at least
> once per day (yeah, I should maybe talk to a psyciatrist about that).
> By default, apt-listchanges show only entries from NEWS files, but I
> reconfigure it with "dpkg-reconfigre apt-listchanges" to also show
> Changelog entries.  In short, I read (or skim, very quickly) all changes
> for all packages on my systems. I learn a lot from informative changelog
> messages.
>
> I find it an amusing little challenge for myself to express changelog
> messages to be both short and informative.  I am not very good at it -
> for inspiration I can recommend looking at changelog messages (and
> mailinglist posts) by Simon McVittie - e.g. gtk4:
> https://tracker.debian.org/media/packages/g/gtk4/changelog-4.6.0ds1-4
>
> I commonly follow one of these patterns for changelog entries:
>
>   * tedious change done
>   * change done, highlighting additions
>   * change done, highlighting additions (highlighting omissions)
>
> Here, I would maybe write (exactly as you - I am no saint, or) like
> this:
>
>   * update webpack command, to be forward-compatible with webpack5
>
> It is common to fit most possible (i.e. as close to 72 chars) before
> wrapping a line.  I instead break at natural "pauses" in the text,
> called "semantic newlines": https://sembr.org/
>
>
> > > Change #2: You update DEP-3 header of a patch
> > will make necessary changes to the patch
>
> I suggest to *drop* that patch: It is not necessary, just makes the
> patch one line bigger.
>
>
> > > fix install in binary packages
> > don't know if that is the right word 'fix' but there were lots of
> > errors thrown from dh_missing as files were not properly installed
> > even for autopkgtest to use. Please if i may ask why the need for
> > another binary file i.e
> > libjs-trust-json-document_0.1.4~dfsg-11_all.deb
>
> I didn't check but am pretty sure that if you did not apply the next
> commit to use pkg-js-tools, then dh_missing would be silent.
>
> So what you "fixed" was your own changes, not something in the previous
> package release, and therefore your "fix" does not belong in the
> _changelog_ (it is not an activity log).
>
> Common procedure when building a package is this:
>
>  a) prepare sources
>  b) configure upstream build system
>  c) do an upstream "build"
>  d) do an upstream "install" to debian/tmp
>  e) copy files from debian/tmp to debian/$PKG
>  f) finalize packaging
>
> Node.js packages often provide no upstream "install" task that fits the
> Debian needs.
>
> This package skipped d) and in e) copies directly from source paths.
> dh_missing should not complain about that.
>
> Your later commit introduces pkg-js-tools to handle d) and e), and
> dh_missing then (correctly) complains that something weird is going on:
> files are copied twice.
>
>
> > > migrate to pkg-js-tools and autopkgtest to handle test suites
> > sure i will revert the change, as i wanted to test with autopkgtest.
> > from my limited knowledge, I switched to pkg-js packaging style. Is
> > there any way I can do that?
>
> Make good sense to improve test coverage.
>
> Yes, it is possible to use autopkgtest without pkg-js.  Not as easy, but
> possible more reliable.
>
> autopkgtest already runs a few superficial tests now, before your
> packaging changes: It is setup in the directory debian/tests/
>
> I guess what you want is to _improve_ autopkgtest, to not only do
> superficial tests but also check upstream testsuite (which is currently
> checked only during build).
>
> Upstream testsuite is not designed to check Debian-installed code. Maybe
> pkg-js magically ensures this, but possibly it accidentally checks
> source code instead, which is less useful.
>
> One example of a package that checks upstream Node.js testsuite and
> ensures that system-installed module gets loaded (not local code) is
> node-lunr: run "apt source node-lunr" and see debian/tests/control
>
> Beware that the upstream testsuite for this package seemingly does *not*
> test webpack-generated code, only uncompressed code - so even though
> including upstream testsuite with autopkgtest _is_ a good improvement to
> the packaging, it will _not_ help tracking if webpack migration works or
> not.
>
> The purpose of webpack is generally to make JavaScript usable in a
> browser, so testing that in principle requires loading the code in a
> browser as well.  test-friendly wrappers for browser JavaScript engines
> exist but are rare in Debian, mainly because compiling a modern web
> browser is a HUUUGE task.
>
> For some simpler Node.js modules, their browser-optimized code can
> instead be tested using a crude emulator of a browser environment.  One
> package that does this is node-domino.
>
> Another even simpler but more reliable test is to only check JavaScript
> syntax without executing the code.  A package to do that is eslint.
>
> Examples of packages doing domino and eslint tests of browser code are
> libjs-bootbox, node-terser, and leaflet.
>
>
>  - Jonas
>
> --
>  * Jonas Smedegaard - idealist & Internet-arkitekt
>  * Tlf.: +45 40843136  Website: http://dr.jones.dk/
>
>  [x] quote me freely  [ ] ask before reusing  [ ] keep private



More information about the Pkg-javascript-devel mailing list