Re: opam (was: Re: Orphaned packages looking for new maintainers)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, May 20, 2021 at 5:15 AM Richard W.M. Jones <rjones@xxxxxxxxxx> 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@xxxxxxxxxxxxx> 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!
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
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@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux