What Fabio just mentioned was that the current use case for a build-time only package is invalid. A lot of packages Mikolaj is trying to get build-time only (via modules) are still maintained by the Java Maintenance SIG because they're required by other packages. Allowing them to be build-time only results in the entire ecosystem crumbling. If they're retired, the ecosystem crumbles too. Same result either way. That's why the Java Maintenance SIG was built: so that it can be more than one person working on these packages. - Alex On Fri, Sep 11, 2020 at 12:44 PM Zbigniew Jędrzejewski-Szmek <zbyszek@xxxxxxxxx> wrote: > > On Fri, Sep 11, 2020 at 06:01:11PM +0200, Fabio Valentini wrote: > > On Fri, Sep 11, 2020 at 5:52 PM Zbigniew Jędrzejewski-Szmek > > <zbyszek@xxxxxxxxx> wrote: > > > > > > On Fri, Sep 11, 2020 at 11:03:39AM +0200, Hans de Goede wrote: > > > > An other more generic approach which has been brought up once or > > > > twice, but which not really has been discussed in much detail yet > > > > I believe is creating a fedora-builddep repository. > > > > > > > > ATM a normal user has 3 ursine Fedora repos installed: > > > > > > > > fedora > > > > fedora-updates > > > > fedora-updates-testing (disabled by default) > > > > > > > > What if we add a 4th repo called fedora-builddep: > > > > > > > > fedora > > > > fedora-updates > > > > fedora-updates-testing (disabled by default) > > > > fedora-builddep (rolling (within a release), disabled by default) > > > > > > > > So the idea is that all the maven deps which you need, but > > > > do not want to offer any end-user support on would go to > > > > fedora-builddep. > > > > > > If we absolutely must have build-only packages, we can do it more simply: > > > insert > > > Requires: fedora-unmaintained-package > > > or > > > Requires: fedora-buildonly-package > > > (name TBD), and beef up dnf a bit to explain that "this package cannot > > > be installed because it's only maintained at the level appropriate for > > > building packages...". I think there are two advantages: first, no need > > > for a separate repo, so there'll be less infra change and churn. Second, > > > this tag can easily set on each subrpm, without any central list to manage. > > > > I'm not sure making things available only at build-time is going to > > help things. It's just "Modularity under a different name" ... > > Most Java packages are either directly or indirectly depended on by > > non-build-tool packages as well. > > You'd be surprised. Most of the distro directly or indirectly depends > > on the Java stack already - including the libvirt stack, libreoffice, > > some GNOME components, KDE components, etc. So most of those Java > > packages can't be built-time-only packages because they're actually > > required at runtime. > > The number of packages that are *really only ever needed to build > > other RPM packages and for no other reasons* is rather small. > > You are probably right. Still, this would be useful to actually have this > surfaced. If a package marked build-time-only would be needed by anything > else, we would need to either unmark it (and have somebody on the hook > for maintaince) or drop the dependency somehow. And this would be vastly > better than build-time-only packages in modules. > > I'm not enthusiastic about build-time-only packages, but if the choice > is between that and retiring the packages (or hiding them in modules > which has the same effect), I'll take it. > > Zbyszek > _______________________________________________ > 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
