RPM Community Forums

Mailing List Message of <rpm-users>

Re: Requires/Provides issue with re-packaging a complex product (endeca)

From: Jeffrey Johnson <n3npq@me.com>
Date: Sun 06 Jan 2013 - 19:40:05 CET
Message-id: <DA29CF6B-FCC8-4F2C-9D32-54390DD06274@me.com>

On Jan 6, 2013, at 12:52 PM, Mykel Alvis wrote:

> Just to clarify, this package is NOT for public consumption.  The software is distributed via installer, to be run by humans.  Since we're doing automation using puppet, an RPM of the code reduces the complexity of the installation substantially and generates a repeatably installable artifact into an existing artifact repository (RH Satellite, in this case).

Most linux distros are development "dog food" aimed at enthusiasts.
Whether one wishes to call that "piublic" is a matter of taste and de facto.

> There actually IS a reason to believe that the ELF data can is, while not wrong, producing undesirable output.  The problem isn't that the dependencies aren't correct.  It's that the package itself supplies those dependencies internally and very specifically doesn't want to external system to interfere with its deployment of the shared libraries.

There is no reason that you have pointed out to suspect that ELF data is wrong.

There are reasosn to suspect that you aren't adding -Wl,soname,YOUR_SONAME_HERE
when building and I asked whether the libraries had DT_SONAME (and give you the readelf
command to verify.

> The package builds very well without turning off the internal dependency generator.  The issue arises when I try to install it and rpm looks at it's huge list of requirements and notes that apparently not all of them are satisfied internally or it would rather I use the packages that it purports work best.  The problem is that they ARE supplied internally and that rpm, during the packaging step, didn't understand that.  I'm not terrible at writing spec files, at least for private consumption, but this seems like it might be something that the rpm developers didn't expect to have to handle as often as I seem to.

THe "buils" is entirely in the eye of the beholder. RPM extracts info from ELF files:
if the "build" doesn't put the correct data into the ELF header, you can blame RPM
all you wish, but its the "buikld" that needs to be fixed.

> The quantity of software that I've had to install using the various shell/executable installer systems is growing, not shrinking.  I attribute this to laziness on the part of the distributor/developer.  They don't take the time to ensure compatibility with various distributions.
> In all fairness, there are an awfully large number of distros to deal with and many/most of them don't take wider-ranging compatibility into account, at least not as a primary element, when getting their (frequently volunteer) packagers to produce their native-level packaging.

Life's tough ... have a kleenex and my sympathies.

> Thus, in this case, this solution is (probably) the only viable one short of writing more code to filter more packages, essentially by hand.  I can't have compatibility with this package because if I stripped out all the perl binaries and used the native perl executables, I might not get what I expected.  Perl has a way of changing across versions and this is a pretty complicated piece of code.  

You may supply whatever reasoning you wish for how you choose to solve your problem.

That won't solve my problem: supply reasonable "support" for unknown RPM problems.

> Because the developers saw fit to package a modified version of code that exists generally in the wild (JDK, perl, probably something that I'm missing), this entire piece of software can either be viewed as a black box (install it all and let it sort itself out) or it would have to be hand-engineered to extract all the pieces that are different and use those as alternates to the ones supplied by standard OS packaging.  I don't have the insight into the product to do the latter, so the former has to suffice.
> Thus, I package it like it was a Big Pile of Obfuscated Code(tm), and it works like a champ.  Scripts inside the code modify library paths to point ot specific versions of specific things and I get a running server.  Woot!

So Ship It!

> Do I think this is a good idea?  No. 
> Do I think that packaging frankenserver versions of perl and the JDK are good ideas?  Definitely not.
> Do I think that software should be written towards wider compatibility with existing packages?  Definitely yes.  
> Do most enterprise software developers seem to agree with me/us?  It doesn't look that way.
> I'm actually speaking at a conference in a few weeks about this specific issue (not the rpm problem, but the "stop writing stuff that's hard to deliver" problem).

Good for you!

Now can you tell me whether your libraries have a DT_SONAME using
	readelf -a /path/to/some/lib/libfoo*.so | grep SONAME

73 de Jeff
Received on Sun Jan 6 19:40:10 2013
Driven by Jeff Johnson and the RPM project team.
Hosted by OpenPKG and Ralf S. Engelschall.
Powered by FreeBSD and OpenPKG.