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.
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.
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.
>
> >
> > 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.
[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
