RPM Community Forums

Mailing List Message of <rpm-users>

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

From: Mykel Alvis <malvis@restorationhardware.com>
Date: Sun 06 Jan 2013 - 18:52:50 CET
Message-ID: <CAC_HrF=2QP0dFqnpNA-Z09Q31TMWrzHNkLiC5HMz=t1LweeDvw@mail.gmail.com>
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.


On Sat, Jan 5, 2013 at 4:01 PM, devzero2000 <pinto.elia@gmail.com> wrote:

> On Sat, Jan 5, 2013 at 10:15 PM, Jeffrey Johnson <n3npq@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
Received on Sun Jan 6 18:52:56 2013
Driven by Jeff Johnson and the RPM project team.
Hosted by OpenPKG and Ralf S. Engelschall.
Powered by FreeBSD and OpenPKG.