-----BEGIN PGP SIGNED MESSAGE-----
On 06/11/2012 10:46 PM, Stanislav Ochotnicky wrote:
Quoting Michel Alexandre Salim (2012-06-08 15:55:29)
> Part of the rationale is that Kushal Das (cc:ed) and myself would
> like to eventually write some Fedora infrastructure in Clojure --
> which would, of course, necessitate having the whole stack in
> RHEL/EPEL 6 as well.
Unless you have a really, really good reason to do it in Clojure
I'd urge you to look into using something that is already available
on RHEL/EPEL/Fedora. No? Read on then...
That was the original motivation, but between the Java tooling issue
and that Fedora infrastructure is mostly Python (and there are
understandable reluctance to switching), we're currently aiming for
parallel Python (for Fedora) and Clojure (for OpenShift) development
for Kushal's Darkserver build ID information repository.
There have been more than one requests before. The truth is
however, that getting whole Maven stack into EPEL will require
*substantial* time investment. Certainly not a 1-man job, and I
assume there will be hard-to-identify bugs resulting from mixing of
older RHEL java packages and requirements of new packages from
Fedora. You will probably have to package additional packages for
> Is there any technical difficulty involved in making these
> packages available on EPEL? If it's a lack of interest, Kushal
> and myself hereby volunteer to be the ones in charge of doing the
> EPEL maintenance work.
Problem is that just figuring out those problems is sometimes
non-trivial because the error messages suck most of the time. You
*will* have to modify a lot of Java packages, such as your new
reviews. It will mean longer and uglier spec files, so at least in
my packages I'd prefer to keep those spec files separate. You will
find that not all RPMs in Fedora correctly state their required
versions for example. Or that some packages are named differently.
Or that we have patches packages to work on JDK 7, so they don't
work on JDK 6 anymore (we don't have it in Fedora anymore).
Yes, I've already noticed several bugs in maven2 subpackages --
normally when some compatibility submodules are not shipped, but it
turns out that the ones that are shipped depend on Maven submodules
where the APIs have changed between 2.x and 3.x.
Speaking of which, could someone take a look at this maven2 bugfix
Another issue is that current Maven was bootstrapped using older
maven2 package. However we don't have that anymore and
bootstrapping maven would have to be reworked from scratch.
We'd actually only need maven2 at the moment -- do you see many issues
in making that available for EPEL? It's not a high priority for us
right now (see first paragraph of response), but it seems to me that
the longer we wait the harder it'd be to do the bootstrapping.
I would suggest making a list of maven dependency tree and have a
look at the number of packages you'd need to package. If that
doesn't scare you off, make a list of packages that are already in
RHEL but different versions. Those might need compat packages. Also
note that for example jakarta-commons-* packages have been renamed
Yikes. But yes, will take a look. When is RHEL 7 arriving again? :)
In short: no one really tried to get Maven 3.x into EPEL because
just figuring out scope of such task is non-trivial. There's too
many unknowns in play there.
That's understandable. It looks like if we're going to do this we
(those who want to see Maven in EPEL) would have to commit to
maintaining the EPEL 6 branch ourselves. Probably going to give EPEL 5
a miss altogether.
I am also sorry to say that you are unlikely to receive much
support from me (as Maven maintainer) and most probably some other
Java folks. Not because we don't want to help, but because you will
be facing issues we haven't seen and just to figure out what needs
to be done would take too much of our time we'd rather spend
working on improving Java packaging for the future. A paradox: you
might get more help from some other distributions who had to go
through bootstrapping Maven when they started using our Java
Same irony with e.g. the Medical SIG -- sometimes other distributions
are further ahead and there's nothing wrong with collaboration.
Michel Alexandre Salim
Fedora Project Contributor: http://fedoraproject.org/
Email: salimma(a)fedoraproject.org | GPG key ID: A36A937A
Jabber: hircus(a)jabber.ccc.de | IRC: hircus(a)irc.freenode.net
() ascii ribbon campaign - against html e-mail
- against proprietary attachments
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
-----END PGP SIGNATURE-----