Hello Helmut, Thanks for starting this topic.
On Tue, 20 Aug 2024 at 07:29, Helmut Grohne <hel...@subdivi.de> wrote: > golang-github-bsm-pool > golang-github-coreos-go-tspi > golang-github-crewjam-saml > golang-github-form3tech-oss-jwt-go > golang-github-go-redis-redis > golang-github-jesseduffield-asciigraph > golang-github-jesseduffield-gocui > golang-github-jesseduffield-pty > golang-github-jesseduffield-roll > golang-github-jesseduffield-rollrus > golang-github-jesseduffield-termbox-go > golang-github-jesseduffield-yaml > golang-github-manyminds-api2go > golang-github-minio-cli > golang-github-tsenart-tb > golang-gopkg-mcuadros-go-syslog.v2 [...] > node-lockfile > node-matrix-js-sdk > node-mermaid > node-node-forge > node-node-localstorage > node-puppeteer > node-trust-webcrypto [...] > ruby-coffee-script > ruby-diaspora-federation > ruby-google-cloud-translate > ruby-jekyll-coffeescript > ruby-jekyll-remote-theme > ruby-omniauth-bitbucket > ruby-riddle > ruby-uglifier > ruby-upr > ruby-yaml-db 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. 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.) Regards -- Héctor Orón -.. . -... .. .- -. -.. . ...- . .-.. --- .--. . .-.
