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

The core issue is that there is a compatibility issue between packages 
that were copied from jpackage into fedora/rhel vs the "official" jpp 
packages in jpackage

The best way to use rhel5 and jpackage is to do a yum remove *.jpp* 
before you try and install anything, then use the jpackage-release rpm 
which sets the jpackage repo as a higher priority than rhel so for 
example when you do yum install ant, you get the jpp5 package not the 
rhel jpp fork of our jpp (v1.7) package

Clear a mud ?  ;)

On 08/02/13 01:12, Matthew Sacks wrote:
> What's the best way to get it fixed (aside from becoming a packager :) )?
> Is there a bug tracking system I should file a bug with?
>
> On Thu, Jan 31, 2013 at 1:36 PM, David Walluck<[email protected]>  wrote:
>> 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.
>>
>> _______________________________________________
>> JPackage-discuss mailing list
>> [email protected]
>> https://www.zarb.org/mailman/listinfo/jpackage-discuss
> _______________________________________________
> JPackage-discuss mailing list
> [email protected]
> https://www.zarb.org/mailman/listinfo/jpackage-discuss


-- 

Will Tatam
Systems Architect

Red Sixty One LTD

UK:	 +44 (0)845 867 2203 ext 103
Ireland: +353 1 485 3506 ext 103