Re: broken dependencies because rpms are in other or development repos

On 01/31/2013 03:58 PM, Nico Kadel-Garcia wrote:
> On Thu, Jan 31, 2013 at 2:13 PM, Matthew Sacks <[email protected]> wrote:
>> Hi List,
>> When I try to install many things using the jpackage-release rpm, I
>> get broken dependencies.
>> Shouldn't the yum repository properly resolve dependencies?
>> Is there a misconfiguration on my end?

No, I am running into the same problem with the build system. I can't
build anything not in devel since the same thing happens there.

I think this happened because Ralph was/is building on a box that
contains the devel release. From devel, you can obviously build down,
but it doesn't work the other way around.

> One of the big proboems I used to have with RHEL 5 was the different
> "jpackage-utils" package, which lacked the
> "/etc/sysconf/java/security.d/rebuild-security-prividers" script and
> caused endless confusion.

Back when I worked on Mandriva, I added that file to their custom
jpackage-utils. But don't blame JPackage for this, blame Red Hat. This
file should have gone in a different package, such as java-gcj-compat or
gcc-java. Something tells me that Ubuntu was a little bit smarter about
this, though I cannot remember right now what they did. But I don't
think Red Hat ever attempted to fix this, since their attitude was that
they didn't care at all about compatibility with JPackage even though it
was apparently fine to take from there. I can't really say the situation
is any better now that Fedora has really broken all compatibility with
JPackage, so don't expect it to work. Maybe an option is to contact
CentOS about fixing it there.

> In addition, apache-solr is *huge* and is  tremendous in its
> dependencies.  It's also wildly out of date: the current release is
> 4.1, while the JPackage version is 1.4.0.  It looks like time for a
> new build: I tried to do that almost 2 years ago, but got into
> dependency hell and numerous Maven required components that also
> weren't in JPackage and for which the original source URL's no longer
> worked.

I have a recent build of the latest lucene 3.x, but in order to build
that I bundled the solr grandparent (and parent?) pom. I have not tried
to build solr yet since it appeared to be quite a bit more complex than
building lucene by itself.