(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 (https://opam.ocaml.org/).
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.
Rich.
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 (https://opam.ocaml.org/).
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 blow!
We'd be happy to take on its maintenance. IIUC it needs to be readopted by August 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 to stay that way.
David
On Wed, May 19, 2021 at 05:38:08PM +0000, David Allsopp wrote:
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 (https://opam.ocaml.org/).
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 blow!
We'd be happy to take on its maintenance. IIUC it needs to be readopted by August 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 to stay that way.
Would you like to become the Fedora packager for opam? You'll need to follow these boilerplate steps (it's not actually as complicated as it appears):
https://fedoraproject.org/wiki/Join_the_package_collection_maintainers?rd=Pa...
and I can be your sponsor.
Rich.
On 19 May 2021, at 18:38, David Allsopp david.allsopp@metastack.com wrote:
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 (https://opam.ocaml.org/).
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 blow!
We'd be happy to take on its maintenance. IIUC it needs to be readopted by August 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 to stay 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.
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. 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 purposes.
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.
regards, Anil
On Thu, May 20, 2021 at 09:43:07AM +0100, Anil Madhavapeddy wrote:
On 19 May 2021, at 18:38, David Allsopp david.allsopp@metastack.com wrote:
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 (https://opam.ocaml.org/).
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 blow!
We'd be happy to take on its maintenance. IIUC it needs to be readopted by August 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 to stay 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 a system.
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 purposes.
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.)
Rich.
On Thu, May 20, 2021 at 10:14:44AM +0100, Richard W.M. Jones wrote:
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.)
https://www.spinics.net/lists/fedora-devel/msg279291.html
Rich.
On Thu, May 20, 2021 at 5:15 AM Richard W.M. Jones rjones@redhat.com wrote:
On Thu, May 20, 2021 at 09:43:07AM +0100, Anil Madhavapeddy wrote:
On 19 May 2021, at 18:38, David Allsopp david.allsopp@metastack.com wrote:
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 (https://opam.ocaml.org/).
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 blow!
We'd be happy to take on its maintenance. IIUC it needs to be readopted by August 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 to stay 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 a system.
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 purposes.
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.)
*I* certainly don't think that. I do think that the method of execution for package reviews sucks, but the fact we do them is important. If we didn't do it, we'd have sloppier packages in Fedora. I'd love for fedora-review to be integrated into Pagure into a set of bots that run to evaluate and give feedback and then have packagers to approve it to merge into the package collection.
On Thu, May 20, 2021 at 3:14 AM Richard W.M. Jones rjones@redhat.com wrote:
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.)
The tool still needs a fair amount of work to really be usable, but it already makes creating a Fedora package much easier than doing it by hand (in my opinion). I haven't been active recently because we are approaching our next software release at $DAYJOB. Once the release goes out next week, I should get some free time back to spend on Fedora and hobby software projects.
On Wed, May 19, 2021 at 4:29 AM Richard W.M. Jones rjones@redhat.com 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 (https://opam.ocaml.org/).
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.
I would like to take opam for Fedora. People who need this package would be easier to install it. Just like pip for Python and cpanm for Perl, which are available in Fedora. People just use the package as it is. They don't urge a full integration with Fedora-shipped Ocaml packages.
And there is a use case in the XAPI community and the Citrix company that a huge opam repo is packaged in a single RPM[1]. They don't ship individual RPM per Ocaml package. They also package opam as an RPM[2]. So, It won't be hard to also maintain the opam RPM in Fedora.
[1] https://github.com/xcp-ng-rpms/xs-opam-repo [2] https://github.com/xcp-ng-rpms/opam
- robin
Rich.
-- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-builder quickly builds VMs from scratch http://libguestfs.org/virt-builder.1.html _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
ocaml-devel@lists.fedoraproject.org
-
Anil Madhavapeddy -
David Allsopp -
Jerry James -
Neal Gompa -
Richard W.M. Jones -
Robin Lee