Re: [Caml-list] Build-/Installation-Tools - not enogh of them?

["Richard W.M. Jones" <rich@annexia.org>]

On Fri, Dec 07, 2018 at 08:31:01AM +0100, Daniel Bünzli wrote:
> On 6 December 2018 at 21:18:23, Richard W.M. Jones (rich@annexia.org) wrote:
> 
> > The problem here is you've gone and invented a second package manager. 
> 
> The problem here is rather that the fragmentation around system package managers renders the development of a consistent and cross-platform package set like is being done in the opam-repository largely undoable without an indirection -- the latter materializing as these nth (sadly usually language specific) package managers.
> 
> > Linux distros already have a package manager, used by users and
> > developers alike. The package manager solves a whole lot of stuff
> > like maintaining the whole system, dependencies, releases, security updates,
> > mirroring and distribution, etc. Having a second one (and let's face
> > it if you're using things like npm, cargo, etc., a third, fourth)
> > complicates everything.
> 
> It surely does. 
> 
> I suspect that if linux distributions had agreed on a single package manager (or even metadata format and package **names**), if this one had added a few developer friendly features (e.g. universes to easily distinguish what you want to compile a project from what you want for your system) and if it had been ported to other platforms we wouldn't need all these language specific package managers. But that's a lot of unfufilled ifs...
>
> The fact that opam v2 became language agnostic largely supports this point. In some of my projects that's the actual package manager I'm using as my integration layer for C packages.
> 
> > However there is likely a good answer here: Tooling to turn opam 
> > packages into RPMs, Debian packages, etc.
> 
> Maybe we should do this the other way round ;-)

There are already efforts to replace all Linux distro package
managers, but they don't have much traction and there's no particular
reason to think that opam is in a good position either, especially
since it does about 5% of what a Linux distro package manager can do.

Most people who want per-user packaging are now using containers,
using the existing Linux distro package managers.

Anyway, tools to take opam metadata and convert it to spec files
and debian/rules are welcome.

Rich.

-- 
Richard Jones