Re: Heads-up: RPM 4.16 alpha coming to rawhide

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

 



On 4/2/20 11:43 AM, Richard W.M. Jones wrote:
On Thu, Apr 02, 2020 at 10:36:58AM +0300, Panu Matilainen wrote:
On 4/1/20 8:40 PM, Richard W.M. Jones wrote:

This is _only_ going into Rawhide / F33?  It looks like the change to
the new OCaml dependency generator will require a complete rebuild of
all OCaml packages.

https://github.com/rpm-software-management/rpm/commit/a6fe37c39b39acbcbd014dd1e6d5653ff84254a1
https://github.com/rpm-software-management/rpm/issues/913


Oh, bollocks. I totally forgot, and failed to realize the impact of
that. Sorry! Should I revert that in rawhiede, until an explicit
"go" signal from you? That's perfectly fine by me.

And yes this is only going to rawhide/f33, only micro version
updates are pushed to stable releases.

No, don't do anything now.  I'm doing an OCaml rebuild of all OCaml
rawhide packages into a side tag.  If that works then we can just fold
that side tag into Rawhide and it's all good.

Ok.

This is also just further proof that these things need to be in
hands of language SIGs, not rpm upstream. Perl and Python dependency
generation was already "outsourced" to respective
lang-macros/generators packages, I'd recommend doing the same with
OCaml to put the right people in control of things like this.

I can't remember but isn't that how it originally worked for OCaml
and then it was added to RPM?

Back then rpm didn't support dependency drop-in dependency generators, so IIRC OCaml dependencies were being created by manually overriding %__find_requires and %__find_provides to the OCaml-specific scripts. Moving it to rpm made sense when there was no other alternative, but since rpm 4.9 with the new dependency generator, the push has been in the other direction. Not entirely unlike a tide, yeah :)

In any case there's probably some value
in sharing this code across RPM-based distributions.  (Note this code
came directly from SUSE, derived from work I originally did for Fedora).

Absolutely. We still haven't figured out a development model that accomplishes this while still giving the control to the language SIGs where it belongs to. rpm-extras is supposed to serve such a role, but miserably failing so far.

	- Panu -
_______________________________________________
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




[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