On Thu, May 20, 2021 at 09:43:07AM +0100, Anil Madhavapeddy wrote:
On 19 May 2021, at 18:38, David Allsopp
> Richard W.M. Jones wrote:
>> (I've added a few opam devs to CC)
>> On Tue, May 18, 2021 at 10:14:41PM +0200, Miro Hrončok wrote:
>>> opam orphan 1
>> weeks ago
>> I didn't notice that opam had been orphaned. This package is the tool
>> used for source packaging of OCaml packages under $HOME
>> I don't especially like language-specific tools for managing packages,
>> because of the usual problems that have been widely discussed elsewhere
>> and it's not profitable to rehash them again. This is my personal view.
>> The question is if we want to keep this in Fedora or not? ie. As an
>> official Fedora package versus something that opam maintainers would
>> provide themselves as a download.
> Thanks for the heads-up - this very week I've wanted to see what could be done
> to get opam into EPEL, so discovering it's orphaned in Fedora is a bit of a
> We'd be happy to take on its maintenance. IIUC it needs to be readopted by
> when F35 is branched, or does an orphaned package get dropped earlier than that?
> FWIW, the aim from the OCaml Community perspective is that opam is installed and
> maintained by the OS's native package manager, so we'd obviously prefer it
> that way.
Likewise, to echo David I'm happy to co-maintain with him in Fedora.
However, was there was a previous maintainer who dropped it and can
we assist anyone else who would like to maintain it? We've obviously
got a scaling problem with the number of distros we support and test
at the moment from the core (and small) opam development team.
Andy orphaned it which means he doesn't want to maintain it in Fedora
any longer. I don't necessarily want to question that decision. I
assume he made for his own good reasons.
Richard W. M. Jones wrote:
> I don't especially like language-specific tools for managing packages,
> because of the usual problems that have been widely discussed
> elsewhere and it's not profitable to rehash them again. This is my
> personal view.
I'd like to push back against this, since there's an obvious need for
language-specific managers since every single language has one.
Well the history of software development is one of fashion-driven
trends and poor decisions, and here we are. Single language
managers don't deal with issues such as:
- How to manage security updates.
- How to develop software written in multiple languages.
- How to centrally distribute packages to many machines.
- How to sign-off bit-for-bit identical software through
a development->QE->production workflow.
- Minimizing distro size on disk and in memory.
- Having a single method to manage/build/patch all packages on
Some of this is now being reinvented badly with containers.
The reason opam exists is that it supports _all versions_ of OCaml
libraries published, and so the database allows developers to
immediately assemble a reasonable universe of packages for their
Fedora packages serve a different need, which are to find a single
set of OCaml libraries and a single compiler version which can build
packages for applications written in OCaml. In the medium term we could
use the metadata in opam-repository to generate RPMs that are well-meshed
with Fedora's standards, and help with compiler version upgrades by
finding a set of versions of OCaml packages that are compatible with
the package set.
There is some tooling written by Jerry James to turn opam metadata
into Fedora packages and with a bit more coordination and development
this could be mostly automated. (Fedora package review gets in the
way, but I think even most Fedora developers think Fedora package
review is the wrong approach.)
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
libguestfs lets you edit virtual machines. Supports shell scripting,
bindings from many languages. http://libguestfs.org