Mikolaj Izdebski wrote:
> Modularity provides not only a different way of grouping or delivering
> RPM packages, but most importantly, a different way of building RPM
> packages.
>
> You get a side tag in Koji where you can have private build-only
> dependencies that are discarded (filtered) once they are no longer
> needed, after module build is done. For build-only packages most of
> security vulnerabilities are not exploitable easily, or at all,
> therefore are low-severity, which greatly limits maintenance work
> required to address them. For example, if upstream tests are ran on an
> obsolete, 12-years old version of Tomcat, I don't need to skip tests,
> but I can package old Tomcat and run the tests. I don't need to update
> that Tomcat or fix security issues as they are not exploitable in
> buildroot - Tomcat runs in embedded mode, does not listen on the
> network etc. Not something that I could with ursine Tomcat packages -
> it would get delivered to users, and we have no control how they use
> it - we would need to fix all important user-reported bugs and CVEs as
> they are potentially exploitable.
>
> Modularity also introduced the concept of API packages - non-API
> packages can have limited usability, with some non-important features
> removed. For example if all I need is a small part of Tomcat, I can
> reduce tomcat package to build just the tiny parts that I need, which
> don't have any dependencies. Again, not something I could do with
> ursine Tomcat package.
But unfortunately, you unilaterally turning most Java packages private this
way is exactly what put the Java stack in the current state, where it is
broken for most other users because the packages they need and were relying
on are no longer available in the public repository.
Tomcat is used by many users, not just as a build dependency (but that,
too), but also on development machines to test web applications and on test
and production servers to deploy them.
Sure, a 12-year-old version is hopefully not what the users will need, but
there the solution ought to be to fix the offending test suite to work with
the current version of Tomcat (downstream if upstream refuses the fix).
> Another, more concrete example: core Ant doesn't have any dependencies
> beyond JDK. It is easy to build and maintain, yet very functional. On
> the other hand, full Ant with all the optional tasks depends on more
> than 200 Java packages. For the purpose of building all packages that
> I am interested in, core Ant with JUnit tasks (total of 3 packages) is
> sufficient. Functionalities of Ant like sending emails or image
> processing are obviously not needed in this case. If building other
> packages is the only use of Ant then it can be maintained much more
> easily (3 instead of ~250 packages). But when Ant is ursine package in
> Fedora then it should be the full Ant - we can't claim to deliver Ant
> to users while it is just part of it. Eclipse in Fedora requires full
> Ant too.
Given the last sentence (Eclipse needs full Ant), I see no realistic way
around packaging the whole thing and not just the minimal subset.
> It's not about the workflow, it is about reducing package maintenance
> work that is required. Modularity allows us to greatly reduce the
> number of packages by patching-out non-API packages to remove unneeded
> features and it allows us to spend less time on fixing bugs in
> packages that are used merely as build dependencies and which we don't
> intend to be used by end users.
But you have to understand that, while all this reduces your workload, it
makes everyone else's (other packagers', developer users', even end users')
life harder.
As far as I can see from this and earlier threads, the packages you maintain
are, in their current form, entirely useless for several potential users.
Personally, I use Java for my day job, but I'm pretty much left using only
OpenJDK from packages. The libraries, we have always bundled JARs ourselves.
NetBeans, I used to use the Fedora package, but it was discontinued years
ago, so I had to switch to the upstream binaries. And now what you have been
doing to Tomcat lately means I am going to have to work with the upstream
JARs there too.
Kevin Kofler
_______________________________________________
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
