Re: Removing more packages from unstable

[Héctor Orón Martínez <hector.oron@gmail.com>]

Hello Helmut,

Thanks for starting this topic.

On Tue, 20 Aug 2024 at 07:29, Helmut Grohne <helmut@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  -.. . -... .. .- -.   -.. . ...- . .-.. --- .--. . .-.