Then you always have the option to package your software for the ones you use and not worry about the rest.

If you want to make your program popular then packaging is part of the process needed.

That's not the problem. (*) The actual problem is that the distro maintainers want split packages (for security and so on), not vendored, and this requirement was already burdensome for many languages other than C/C++. If vendored packages were acceptable I believe people would have of course contributed them. Maintainers made this obstacle themselves (for a good cause, arguably) and it seems farfetched for them to then complain other languages are uncooperative.

* Was "isn't that a problem?", which was not I meant to say.

> If you want to make your program popular then packaging is part of the process needed.

That is demonstrably not true. I'm not making a value judgment (maybe it SHOULD be true, I dunno), but it's not true. There's a lot of popular unpackaged software out there.

I mean the whole argument here is that distro packaging is not needed, that there's a better way of doing it.

That actually clarifies some thing about the debate for me. Thanks.

I'm not sure I'm convinced based on the semi-frequent posts from maintainers and security pros about the issues with vendoring dependencies for software that is widely deployed.

This "better way", since we lack a more concrete name. Seems to be really great if you're running a web app, or server software in your own company and can rebuild and run a rolling deploy pretty easily. For someone pushing software to users all over the world, and as one of those users the downside to allow every application to be responsible for updating this stuff seems pretty steep.

Not anymore