3:29 p.m.
(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 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
12:38 p.m.
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
3:24 a.m.
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...
and I can be your sponsor.
Rich.
--
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
3:43 a.m.
On 19 May 2021, at 18:38, David Allsopp <david.allsopp(a)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
4:14 a.m.
On Thu, May 20, 2021 at 09:43:07AM +0100, Anil Madhavapeddy wrote:
On 19 May 2021, at 18:38, David Allsopp
<david.allsopp(a)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.
--
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
4:43 a.m.
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.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-p2v converts physical machines to virtual machines. Boot with a
live CD or over the network (PXE) and turn machines into KVM guests.
http://libguestfs.org/virt-v2v
6:51 a.m.
On Thu, May 20, 2021 at 5:15 AM Richard W.M. Jones <rjones(a)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(a)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.
--
真実はいつも一つ！/ Always, there's only one truth!
4:07 p.m.
On Thu, May 20, 2021 at 3:14 AM Richard W.M. Jones <rjones(a)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.
--
Jerry James
http://www.jamezone.org/
3:28 a.m.
On Wed, May 19, 2021 at 4:29 AM Richard W.M. Jones <rjones(a)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(a)lists.fedoraproject.org
> To unsubscribe send an email to devel-leave(a)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
931
days inactive
937
days old
ocaml-devel@lists.fedoraproject.org
8 comments
6 participants
participants (6)
-
Anil Madhavapeddy -
David Allsopp -
Jerry James -
Neal Gompa -
Richard W.M. Jones -
Robin Lee