Quoting Vincent Bernat (2022-02-14 21:35:47) > ❦ 14 February 2022 10:56 +01, Jonas Smedegaard: > > >> I've finally give up and am just using ALL the bundled node > >> packages: > >> https://salsa.debian.org/chromium-team/chromium/-/commit/a418d219f0217d6398a01c30035d35c42f7a76f1 > >> > > > >> It's not ideal, but at least with this we'll match all of the node > >> stuff with what upstream is testing, with the single exception of > >> nodejs itself (which we're still using from debian). The only other > >> alternative I can think of is to get all the node packages into > >> debian, and they'd also need to be backported to bullseye. I > >> haven't looked into this yet, but it might be necessary if upstream > >> breaks compatibility with nodejs 12. So, uh, if anyone is bored and > >> looking for some node packages to maintain.... :) > > > > I fully recognize the pain of maintaining a big package and then on > > top of that paying attention to packaging a pile of Node.js modules. > > > > It is also, however, a pain to maintain a pile of Node.js modules > > and then on top of that paying attention to big packages struggling > > with bundled Node.js modules. > > > > Suggestion: Please consider filing RFP bugreports for each Node.js > > module that you give up on unbundling. That is far more helpful > > towards delegating the work than mentioning deep inside a > > mailinglist thread without "help needed packaging Node.js modules" > > as subject. > > > > A next step (independent, not necessarily by you) could then be to > > user-tag RFP bugs tied to unbundling, to help prioritize those among > > the many WNPP bugreports. > > Unbundling also means that each update may require waiting for many > dependencies, leaving users vulnerable in the meantime. Firefox has a > very good track record with updating both in unstable and in stable > thanks to glandium uploading new version the day after the release. I > don't know what the bundling state is, but even with such a good track > record, it sometimes lag a bit behind upstream due to dependencies. > Currently, Firefox 97 is waiting for a rust update and nothing seems > to go forward. Once someone will move forward, it seems we will have > to also wait a bit on the NEW queue due to the rust update (most of > the time, I think rust gets quickly approved in a day or two). I have > myself switched to the binaries provided by Mozilla. I'll switch back > once unstable is up-to-date again because I am confident this won't > happen often, but I suppose at some point, I will switch to the > Flatpak, like I did for Chromium. > > My point is that packaging dependencies independently will just lead > us to difficult to package browsers with maintainers giving up. Browsers are difficult to package for several reasons. Availability of separately packaged dependencies is not one of them. Use of separately packaged dependencies might be a reason, if not done well. I am obviously not suggesting to do lousy packaging work. I am trying hard to read good faith into your last sentence above, but have quite some difficulty reading as anything but you describing unbundling as inevitably leading to disaster. Maybe my point was unclear, so let me try again: When maintaining a package with embedded code copies, then please if giving up on unbundling at least file RFP bugreports so that others can help. Help *you* the package maintainer, who has the final say on when and how such separately packaged dependencies is used to *improve* your maintenance (not make your work harder or drive you towards giving up). - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private
Attachment:
signature.asc
Description: signature