It appears that the idea is to build binaries in the buildsystem using maven instead of a chroot with rpmbuild, then dump those binaries into an srpm with a minimal spec file to install those binaries onto the system and then distribute the rpm built from that. This violates some pretty fundamental assumptions of how we package. The listed drawback that rpmbuild --rebuild will no longer be able to rebuild a package from source is a very serious change to our current policies that I think is a showstopper in and of itself. However, I think this proposal attempts to be true to some of the spirit of why we build via rpm while attempting to build via this new method so it deserves more than just a gut response. Let's try to break down some of the problems with this proposal, identify the problems it's trying to address, and work out a better solution.
High Level Goal Confusion
The first problem is that this isn't clear about what problem we're trying to solve. The "Why should we use it?" section attempts to do this but I don't know what we're after even after reading it several times. Here are several possibilities:
- Make building rpms with maven easy.
- Make building JBoss possible.
- Get rid of the current hacks.
- Do away with rpm as a build mechanism.
- Make packaging Java applications take less time.
Of these, I think that only the middle one matches up with Fedora goals. If there are hacks involved with the current build process that do not need to be there then we should get rid of them. Simplification is good.
The first two and last potential goals are possible nice-to-have's along the way towards Fedora's major goals. Yes, we want packaging to be as easy as possible. Yes, we want to take up less time on packaging so we can package more quality software. Yes, we want to be able to package things like JBoss. However, we should not compromise Fedora's goals of valuing quality over quantity, making packages that other people can look to as an example of building rpms correctly, or being a secure, maintainable distro to achieve them.
The fourth goal, doing away with rpm as a build mechanism is a non-goal of Fedora. It's practically a non-starter for this discussion. We want people to be able to take our packages and reproduce them on their own. We want them to be able to modify them and build their own derivative distros. Tying derivatives to our buildsystem rather than to the individual rpms is a heavy price that I don't think we should be prepared to pay. Fedora Infrastructure has found that koji is not a lightly deployed tool. Forcing derivative distros to have to deploy koji in order to rebuild all of our packageset is not fair to our downstreams.
Identified Problems Don't Seem to be Solved
Although the high level goals are a bit muddy, the "Why should we use it?" section does talk about the problems that keep us from reaching the potential goals that I outlined.
- Maven presupposes that we'll have a repository of java packages inside of a Maven repo.
- Maven builds want to pull in multiple versions of a package.
- The current Fedora Java Guidelines lead to fragile dependencies between packages.
- The current Fedora Guidelines are complex
- Some application systems (such as JBoss) have a lot of dependencies that need to be built. This is a complex process when building independent rpms.
Except for #1, none of these problems will be solved by having a new koji backend using maven. These are issues where policy is conflicting with convenience. If we had a maven-based buildsystem, the same policies as we have currently would continue to cause these issues to occur. Let's take them in order:
2) Multiple versions. Currently Fedora discourages multiple versions but doesn't ban them. I believe that there is policy at the FESCo level surrounding multiple versions (which is why we don't currently have multiple versions of python, for instance). The problem with maintaining multiple versions is that most often, upstream only cares about one or two versions of their software. If we are packaging more versions of the software to satisfy dependencies than upstream supports, then we become responsible for the extra versions. If a bugfix or security fix is needed, then we become responsible for generating that for all the versions that we maintain. This type of backporting is counter to Fedora's goal of being a forward moving distro. Normally we work to port applications forward to new versions of libraries to keep the number of libraries to a minimum and soease our overall support burden over time. Having a new, maven-based build system won't change this policy. If FPC or FESCo or simply reviewers consdering these issues won't approve all the versions you think you need it doesn't matter whether the buildsystem is rpmbuild or maven based.
3) Guidelines are fragile. The Fedora Packaging Committee has taken the Guidelines that Java Developers have issued for creating Java Packages with minor changes. If they are fragile, then the Guidelines need to be fixed to be more robust. Remember that the Guidelines aren't going to change merely because we have a new buildsystem. We went from plague to koji without the Guidelines making one koji-specific change.
4) The Guidelines are complex. Once again, fix the Guidelines. If there's resistance to changing something about the Guidelines switching buildsystems isn't going to make it any better, the requirements are still going to be the same.
5) Bundled libraries are prohibited by the Guidelines. This is not going to change just because we have a new buidsystem. You mention that "Koji-Maven would enable us to build JBoss from source using the upstream build process" but that's not true. If JBoss is relying on bundled libraries, it will have to be split up whether the build process goes through a maven-based koji or an rpmbuild-based koji. If you want this to change, you need to get the Guidelines changed. And a word -- Lots of people attempt to get an exception to this Guideline. That's the wrong way to pursue change. Show that the Guideline is either not beneficial to the distribution or that the costs of following the Guideline warrant coming up with other ways to mitigate the problems the Guideline is fixing. This should be something that can apply to all packages in the distro.
Additional Costs
- Complexity. We'd have to build and maintain two backends to koji instead of
one.
- Content delivery to end users becomes more complex. Whereas we currently
only have to explain the process of downloading and building from srpms to users and customers who want to rebuild our rpms with only minor changes or verify source, CFLAGS, etc, or only run their own binaries with this change we would need to educate them on both rpmbuild and maven.
- "Self-hosting" is less meaningful. Right now, every rpm we build can be
built in a straightforward manner on Fedora. You satisfy the BuildRequires and run rpmbuild --rebuild. The necessary tools are in Fedora and pushing BuildRequires into the system is a task that has many tools to help out. (mock, yumbuilddep, etc). With this proposal, we would create an environment where our builds would not be done on pure Fedora anymore. The same content might be available in rpm format but the build environment would be different since we're building using a maven repository whereas the user is building with rpms installed locally.
- Our obligations under the GPL become a little less clear. When we talk
about the distro as a whole being licensed under the GPL we are promising to give out source to rebuild the distro. This has always meant srpms for us which not only give the user the source for the applications themselves, but the source for recreating the exact binary rpm that we used. With this proposal, the srpm no longer does that. We may still be within our legal rights (have to talk to a lawyer about that) but this is one of the things we have blasted other distributions, and upstreams that distribute binary rpms and source tarballs but not srpms/spec files for doing.
- Packagers and reviewers will have to learn about both maven and rpm spec
files in order to use this. Building a package locally as part of the review process will have to be worked out -- this proposal isn't detailed enough to tell me what the equivalent of mock SRPM would be for java packages. there's an increase in work and knowledge here that counters any decrease that occurs from having simpler rpm spec files.
Counter Proposal
Instead of making a maven repo in the build system at build time, why don't we make a maven repo on the local system at install time? For Fedora, have every jar be installed to some location by rpm. Then the rpm %post script runs to regenerate whatever metadata is needed to make it a maven repo. If maven is really the de facto standard for building Java jars, this will help not only us when we build (because our srpms will just point at the local maven repo that's created from all the java rpms that are installed in the chroot) but also the developers on Fedora systems who can now point their toolset at the maven repo that gets built locally.
--abadger1999 05:58, 26 September 2009 (UTC)