On Mon, Apr 8, 2019 at 12:21 PM Mikolaj Izdebski <mizdebsk@xxxxxxxxxx> wrote:
>
> On Sat, Mar 30, 2019 at 1:34 AM Christopher <ctubbsii@xxxxxxxxxxxxxxxxx> wrote:
> >
> > On Fri, Mar 29, 2019 at 5:24 AM Mikolaj Izdebski <mizdebsk@xxxxxxxxxx> wrote:
> > >
> > > On Thu, Mar 28, 2019 at 7:46 PM Christopher <ctubbsii@xxxxxxxxxxxxxxxxx> wrote:
> > > >
> > > > On Thu, Mar 28, 2019 at 9:50 AM Mikolaj Izdebski <mizdebsk@xxxxxxxxxx> wrote:
> > > > > - javapackages-tools, stream 201801 (buildroot-only module, not
> > > > > intended to be delivered to users)
> > > >
> > > > How do I enable/install this module locally? It would be very helpful
> > > > for local builds/testing, but is not available in:
> > > > sudo dnf --releasever=30 module list
> > >
> > > The official, recommended way of building modules locally is "fedpkg
> > > module-build-local". This command should take care of fetching and
> > > installing all required dependencies specified in modulemd being
> > > built. Therefore in this case it is enough to add dependency on
> > > javapackages-tools and it should "just work", for both local and
> > > remote builds.
> >
> > Hmm. I don't know how to do modules yet. I don't know how to create a
> > modulemd, or where it lives, or which packages I need to put in which
> > module, or how to name modules, or anything. I just want to install
> > all the tools from javapackages-tools, so I can do a plain old `fedpkg
> > local` build of my regular RPMs. I know this isn't going to work in
> > Koji for Fedora... but it would help me, as a user of those tools,
> > have access to them for my own RPM building purposes.
>
> You don't have to use these packages. You can keep using traditional,
> "ursine" Java packages that are still available in non-modular repos.
> These packages new owners who signed up to maintain them.
>
I know I don't have to use them, but... I *want* to use them. My
understanding is that those new owners maintaining them is an interim
solution, *minimally* maintained to prevent catastrophe, not the
stable long-term solution. I'd prefer the go to where the fully
maintained packages are going... not stay with the minimally
maintained ones. Besides, the catastrophe can still occur, if we don't
work to migrate while we have the chance.
> In addition to the above set of traditional, "ursine", packages, there
> is also javapackages-tools module, that contains Java packages
> intended for building certain other modules. Module maintainers can
> choose whether they want to build their modules using ursine Java
> packages, or using javapackages-tools module. Ursine package
> maintainers have no such choice and they are limited to depending on
> ursine Java packages only.
>
I'm trying to get on board the modular train, and convert my ursine
packages to modules. I want to learn how to do this correctly locally.
How can I get local builds of my modular packages, using the versions
I want them to use from the javapackages-tools module? I think the
lack of local availability of the packages in this module will make it
harder to transition to the modular versions, and will keep the
requirement for the ursine packages around longer.
> The original goal was to have a single set of modular packages that
> would be used for both building other modules and for building
> non-modular ("ursine") packages. However, in the end this set was
> split/forked and now we have two package sets, but with different
> maintainers. These packages are similar for now, but I expect them to
> diverge more over time. I don't like this situation either, but I've
> done everything I could to avoid it.
>
I understand, and appreciate what you've done to sound the alarm, and
the effort you've put into these packages to benefit the Java
ecosystem within Fedora. That's why I'm trying to follow the path
you're going, rather than stay on the ursine packages. I'm just
finding it extremely difficult to do so, because I do not understand
how to do modules, and the fact that some of them are less available
than others, makes it hard to "play" to learn on my own.
> >
> > >
> > > The module is not included in any compose, therefore dnf won't be able
> > > to find it in default repos. If you really want to install the module
> > > on your system for some reason then you can use ODCS [1] to generate a
> > > compose containing the module. Install ODCS client with "dnf install
> > > odcs-client" and then request compose with "odcs create module
> > > javapackages-tools:201801". ODCS will (usually) quickly create repo
> > > with the module and output repo URL, which you can put in a config
> > > file under /etc/yum.repos.d/, or pass to dnf using --repofrompath
> > > option. Note that contents of javapackages-tools module are not signed
> > > and therefore you need to skip GPG verification in order to be able to
> > > install it.
> >
> > It seems a bit crazy to me that we have packages built for Fedora that
> > aren't available for users to install. Why wouldn't we make everything
> > maximally available? I used to love Fedora, because I just play with
> > all the bits. But now, a lot of those bits are going away... I have
> > less to play with... and the focus seems more targeted towards
> > Fedora's internal needs, and not Fedora's users needs. Contributing to
> > Fedora is so much harder now. Do we have to make it harder by making
> > certain packages unavailable to regular users (and casual
> > packager-contributors like me)?
>
> We already have packages that are built by Fedora and for Fedora, but
> are not distributed to users for various reasons. These include
> glibc32, some buildroot overrides and even non-distributable-rpms [1],
> which are not only not included in Fedora repos, but also users are
> also blocked from downloading them from Koji.
>
I wasn't aware of the precedent, because the current situation is the
first time it has impacted me. From the linked precedent, it still
seems like that should be a last resort... an exception, not the norm.
Plus, I think there are things valuable to users, not just packagers,
contained in javapackages-tools (build-classpath, for example).
> [1] https://fedoraproject.org/wiki/Non-distributable-rpms
>
> --
> Mikolaj Izdebski
> _______________________________________________
> 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
_______________________________________________
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
