On Wed, Aug 21, 2024 at 03:39:11PM +0200, Héctor Orón Martínez wrote: > I am surprised to not see more of those packages in the list, there > are many packages in those ecosystems with popcon between 1-10 users.
popcon wasn't used when building this list though (even via the key packages condition, because AFAIK popcon is no longer used there). Most libraries just don't have RC bugs. I checked several from the list: golang-github-crewjam-saml - unfixed CVE, "Let's remove it from bookworm. No reverse dependency.". There is a git commit with a new upstream version that wasn't uploaded. golang-github-jesseduffield-asciigraph - "Don't release with bookworm", looks like it's not buggy, just useless. node-mermaid - FTBFS, has git commits with fixes (not for everything I guess) that weren't uploaded. node-trust-webcrypto - FTBFS ruby-diaspora-federation - FTBFS ruby-uglifier - FTBFS > I have also been wondering if we could take a different approach for > packaging libraries for language ecosystems that already have > packaging managers to play nicer with Debian packaging > maintainability. I find myself when I need to use such libraries I > need to build my own bundle to support specific applications since > Debian packaged versions don't tend to work well with the application > (the same is true for Rust, Python, etc.) It's a very big and very controversial topic (at least if by "don't tend to work well" you mean that we have too old or in some cases too new versions). -- WBR, wRAR
signature.asc
Description: PGP signature
