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).
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. 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 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. 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. 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! 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). Thanks again to you both. You have saved me days of frustration and I owe you both a beverage of your choice. Mykel On Sat, Jan 5, 2013 at 4:01 PM, devzero2000 <pinto.e...@gmail.com> wrote: > On Sat, Jan 5, 2013 at 10:15 PM, Jeffrey Johnson <n3...@me.com> wrote: > > > > On Jan 5, 2013, at 4:02 PM, Mykel Alvis wrote: > > > > > > devzero2000 over on the rpm-users list suggested > > %define _use_internal_dependency_generator 0 > > > > > > This did exactly what I needed. > > > > > > > > Yes but … there are profound changes to the *.rpm package > > format that are coupled to setting %_use_internal_dependency_generator > to 0. > > > > That macro was _NEVER_ designed to be flipped around on a per-package > basis > > by package monkeys. > Yes, but apparently autoreq to 0 doesn't work on the sharelib deps on > rpm 4.8 (@rpm.org). I have seen > ocaml package setting %_use_internal_dependency_generator to 0 before > ocaml deps was included in rpm. > http://markmail.org/message/hdwyn3ys675psmcz > But perhaps i am missing something, probably. > > Best regards > ______________________________________________________________________ > RPM Package Manager http://rpm5.org > User Communication List rpm-users@rpm5.org >
