Le lun. 10 févr. 2025 à 06:43, Martina Ferrari <[email protected]> a écrit :
> Hi all, > > A bit late to the party, but I have just uploaded prometheus 2.53.1 to > unstable, after a long wait due to the constant problem of outdated or > missing dependencies. > > This is the last LTS (lont-term support) release of the 2.x series, so I > really wanted to have this in trixie. As things stand, we won't be able > to upgrade to 3.x in time, plus there is no 3.x LTS release yet; so I > think this is a good version to include in trixie. > > Considering all this, it might be worth seeing if it is possible at all > to try to build the "old" react UI from source, resorting to vendoring > in NPM dependencies, as it looks that the lit might not be that long at > this point. In the last couple of years, I have gained quite a bit of > experience with JavaScript and NodeJS (on the backend side mostly), but > I still struggle with the Debian packaging tools. So maybe with a bit of > help with somebody from the JS team we can try this? > > > i *think* the "react-app/" directory is the older implementation, > which > > can be disregarded. > > This would actually be the one we can try to build, which corresponds to > the list of dependencies Daniel listed in October. > > On 07/10/2024 19:08, Jérémy Lal wrote: > > I think the proper method will be to mut-bundle as much, and as cleanly, > > as possible, > > Jérémy, could you explain what do you mean by "mut-bundle"? I can't find > any package name resembling that.. > A multiple upstream tarball, example of watch file: https://sources.debian.org/src/node-webfont/11.4.0+dfsg2+~cs35.7.26-10/debian/watch/?hl=12#L12 I'm sure what's the best package to serve as an example of dh-nodejs usage, however it's good to skim through sources.debian.org, and read https://wiki.debian.org/Javascript/GroupSourcesTutorial > > with most packages not re-exported to /usr/share/nodejs, because it is > > just asking for trouble. > > Agreed. > > There are tools to help in that task, like pkgjs-tools' > add-node-component. > > Would this be using multiple source tarballs? I wonder if that wouldn't > conflict with the usual workflow where we don't rely on pristine-tar but > on upstream git history. I never found a way to make both (m.u.t. and upstream git history) work. Maybe it's possible, though. I guess an option could be to package this in a > separate source package, but I'd like to avoid any extra steps and trips > to NEW. > The simplest solution, by far, is to switch to the other gbp layout (without git history). Jérémy
