Debian, Rust, and librsvg

Posted Nov 18, 2018 21:22 UTC (Sun) by roc (subscriber, #30627)
In reply to: Debian, Rust, and librsvg by epa
Parent article: Debian, Rust, and librsvg

That has all the disadvantages of vendoring the library, as far as I can tell, and some additional disadvantages.

Like vendoring, you have to do a bunch of ongoing work to import the libraries and track their evolution.

Unlike vendoring, you need an extra server-side repository that has to be replicated *per distro* and probably per major version. This has to be built, tested and maintained as all distros evolve. No thanks.

Debian, Rust, and librsvg

Posted Nov 18, 2018 21:22 UTC (Sun) by roc (subscriber, #30627) [Link]

Also, this can't solve the problem for applications that want to deploy on platforms where there isn't library package management, whereas vendoring does solve that.

Debian, Rust, and librsvg

Posted Nov 19, 2018 15:39 UTC (Mon) by epa (subscriber, #39769) [Link]

I was kind of assuming you'd build your binary per distro and version anyway. But if you have the same binary over multiple versions of the same distro, or over multiple distros, then you could have the same repository for them too. (Though the distros make this needlessly hard by using different names for the same packages, so a package listing dependencies for Fedora often won't work on SuSE, even if the binary itself would.)

I mentioned this way because I think it's what Adobe did for packaging acroread. Though it seems they have now given up on Linux altogether.

Debian, Rust, and librsvg

Posted Nov 19, 2018 18:46 UTC (Mon) by jccleaver (guest, #127418) [Link] (1 responses)

> Unlike vendoring, you need an extra server-side repository that has to be replicated *per distro* and probably per major version. This has to be built, tested and maintained as all distros evolve. No thanks.

That's... not very difficult. Plenty of vendors do exactly that, for any repos that they support. Yes, this is why Fedora's 6 month releases aren't supported, but if you're a professional, enterprise shop the ability to do this against stable targets is pretty trivial. If you're building one or more RPMs already for your own software, separating bundled libraries into their own RPMs too is not difficult, and is certainly a good practice.

Debian, Rust, and librsvg

Posted Nov 19, 2018 21:27 UTC (Mon) by roc (subscriber, #30627) [Link]

What about those of us who aren't "professional, enterprise shops" and just want to make software available in a way that every Linux user, even Fedora users, can easily consume? And though this approach creates a pile of ongoing work for the software vendor, it also brings back the issue of whether you trust the application vendor to choose good versions of dependent libraries and keep them up to date.

The Rust approach --- modern dependency management with a global library repository and static linking --- is far more appealing to developers than "set up your own package repository for every distro your users care about".

At some point it may be worth extending crates.io with labels for trusted library versions. Even then it will still be a far more efficient and practical system for managing dependencies than anything C/C++ have to offer.