On Tue, Jul 30, 2019 at 5:48 PM Alexander Scheel <ascheel@xxxxxxxxxx> wrote:
----- Original Message -----
> From: "Christopher" <ctubbsii@xxxxxxxxxxxxxxxxx>
> To: "Development discussions related to Fedora" <devel@xxxxxxxxxxxxxxxxxxxxxxx>
> Cc: "Fabio Valentini" <decathorpe@xxxxxxxxx>
> Sent: Monday, July 29, 2019 6:14:57 PM
> Subject: Re: Over 500 orphaned packages seeking new maintainers
>
> On Mon, Jul 29, 2019 at 5:36 PM Alexander Scheel <ascheel@xxxxxxxxxx> wrote:
> >
> > > Question (not for Fabio specifically, but for the list) modules can have
> > > (Build)Requires on other modules
> > > right?
> >
> > Yes, if the module maintainer is willing to expose their module in the
> > BUILDROOT. That was PKI's problem: mizdebsk orphaned the ursine packages,
> > exposed them in a module available only at runtime, and refused to open
> > it up for build-time use. He wanted us to maintain our own versions of
> > all of the packages we use that he modularized.
>
> I don't think "refused" is a fair characterization. My understanding
> of the problem is that creating a module is new (and change is hard),
> and unnecessary for most basic packages, so long as their BRs are
> available. Maintaining many of the java BRs across multiple releases
> was becoming burdensome, so mizdebsk decided to take advantage of
> modules to reduce their work load. The ideal at that point was to
> expose modules to the ursine BUILDROOT, in order for ursine packagers
> to have BRs on them without having to themselves be shipped in a
> module. Without that, lots of ursine packages were going to suffer,
> and that's what happened. Fedora is now extremely hostile to Java
> packagers, unless 1) the java packager is willing to take on dozens or
> hundreds of packages, or 2) the java packager is willing to learn how
> to do all this module stuff.
>
> I don't think it's fair to say that mizdebsk "refused" to open them up
> to build-time use... but perhaps fair to say that they refused to open
> them up to build-time use, when that didn't solve the underlying
> problem (because they would still only be available to modular
> packages, and not to ursine ones, which is what was needed).
This actually has nothing to do with modules vs. ursine packages. mizdebsk
maintains a very small API on his modules. This limits what other modules
can do with it, including in the BUILDROOT. So when our first attempt to
save Dogtag was to modularize it (into the now-deprecated pki module),
we realized that wouldn't work *because* of that small API. It simply
didn't contain what we needed.
We reached out to mizdebsk and his stance was that we should bundle all
our dependencies (that he modularized) into *our* module, maintaining
*separate* streams from his. This is completely unworkable at scale. He
didn't want to expand the API. We put our time elsewhere and stayed ursine.
I think "refused" is thus a fair categorization.
And you offered him to take ownership, right? I just couldn't stand looking how the single guy keeping Java ecosystem working in Fedora for a number of years is being *blamed* for not doing exactly what others need and I haven't heard of *anyone* actually proposing to take some of his load.
> At least, that's my understanding of the situation.
>
> FWIW, I'm probably going to orphan the last of my Java packages, too,
> because I don't have time to figure out how to create a bunch of
> modules just so I can get the BRs I need. My time would be better
> spent building ursine packages in COPR, outside of Fedora's modularity
> efforts. I've been watching keenly, to see if the situation will
> change, and Fedora will become Java-friendly again, but I don't see
> that happening, sadly.
Right, and perhaps you'll get lucky and your modules will work because
your BRs are exposed in the API of modules. But until then, the SIG is
picking up hundreds of packages just to keep the entire ecosystem alive
and to help out those maintainers who don't have time or don't want to
modularize.
> _______________________________________________
> 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
>
_______________________________________________
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
--
Alexander Kurtakov
Red Hat Eclipse Team_______________________________________________ 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
