Comment # 1
on bug 1143
from Nathan Scott
Hi Zack,
The pcp-webjs code is not part of PCP. Hence its not really appropriate to deb
package it as part of the core PCP build (although there are options like we do
for rpm, see below). You could open a github issue (that seems to be the only
upstream bug tracker for pcp-webjs, AFAICT?) and request debs there ...
https://github.com/performancecopilot/pcp-webjs/issues
... but upstream projects rarely do packaging, so you might find no luck there
either. Someone would have to sign up to do the deb packaging work (the person
who maintains the PCP deb packages has expressed concerns about packaging
pcp-webjs in its current state).
There seems to be no actual release model for pcp-webjs, no documentation, and
it still contains a redundant, dated copy of Vector for some strange reason, in
spite of numerous requests for its maintainer (fche) to stop duplicating that.
If those issues were resolved, we could consider producing debs via the
mechanism Raphael describes here (this is like the rpm model we use today):
https://raphaelhertzog.com/2010/09/07/how-to-use-multiple-upstream-tarballs-in-debian-source-packages/
Alternatively, Vector and webjs could just be deb packaged "properly", as the
standalone projects they are, with their own bintray repos. Vector already has
one setup, pcp-webjs could certainly have one too (that might also help to
define a release process for pcp-webjs).
Ultimately though, either of these approaches is going to require someone to
volunteer time & effort to make it happen - I'm swamped, such that even the deb
packaging of pcp is falling behind (lacks systemd support, pmda sub-packages &
proper dependencies, automatic pmda ./Remove on package removal, etc, etc... it
is alot of work as-is - so my vote is for option #2 at this stage).