Re: F30 Self-Contained Change proposal: Bash 5.0

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

 



On to, 07 helmi 2019, Jerry James wrote:
On Thu, Feb 7, 2019 at 2:13 AM Adam Samalik <asamalik@xxxxxxxxxx> wrote:
2) Fedora infra builds of standalone packages — modular content is currently invisible to standalone package builds. That said, the Modularity Team is actively working on making that possible. You might have heard about "Ursa Major" which is a funny name for a solution that injects default module streams into the traditional buildroot. Alternatives have been also discussed in the past few weeks. But please understand this the reason it doesn't work at this moment is not the design, but rather the work still being in progress. And before that's done, we do not allow packages used as build dependencies to be completely moved to a default module before we fix this — so nothing should break for you.


A couple of days ago, Mikolaj Izdebski announced on this mailing list,
in a thread entitled "Orphaned some Java packages" that 259 packages
are being converted into modules.  So none of those are used as build
dependencies?  I can tell you for sure that one of them SHOULD be used
as a build dependency:

https://bugzilla.redhat.com/show_bug.cgi?id=1599015

What should happen is that coq has antlr4 as a build dependency, uses
it to generate some python code, then depends on the antlr4 python3
runtime.  Since that isn't possible at the moment, I've been forced
into the stupid, wrong workaround of (a) using upstream's generated
python code, since our antlr4 package is incapable of regenerating it,
and (b) bundling the antlr4 python3 runtime with coq, since it is not
available from Fedora in any package.  Now what is going to happen?
If antlr4 becomes a module, how will this situation be resolved?
Coq might become a module stream itself, with its modular content
being exposed through a default profile that is available without
explicit enabling of a coq module to any (non-buildroot) use of Fedora
packages.

It is another option, not worse than others.

For my experience with modules...

We didn't go with modules for FreeIPA in Fedora yet but I spent last
year doing modularization of RHEL IdM. My worries were basically on
having a lot of overhead for maintaining packages. They did not really
came through: apart from a need to coordinate rebuilds, modular RHEL IdM
is actually helping us to be more clear with the dependencies and their
use.

In Fedora the use for our dependencies is wider than in RHEL, so the
same benefits might not be so apparent.

--
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
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