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
please?
73 de Jeff
______________________________________________________________________
RPM Package Manager http://rpm5.org
User Communication List [email protected]
