RPM Community Forums

Mailing List Message of <rpm-users>

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

From: Mykel Alvis <alvis.mykel@gmail.com>
Date: Sun 06 Jan 2013 - 21:34:53 CET
Message-ID: <CAFYWm_Lwc8oCbOgZ2sS=H251Ghb_CrinGZz679x-JFdMvSD=0g@mail.gmail.com>
On Sun, Jan 6, 2013 at 12:40 PM, Jeffrey Johnson <n3npq@me.com> wrote:

> 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.
While I appreciate your help here, you might have gotten a couple of
incorrect impressions.

First, it seems that you might think that I'm blaming rpm for any of this.
I am definitely am not.  These issues are a result of poor practices by the
original builders of this code

Second, that I have some matter of choice in what I use to solve this
problem.  I do not.

Third, that being snarky is appropriate.  I'm having an issue dealing with
something that was dropped into my lap.  I know it's the internet, that you
are, quite literally, replying to me mostly out of good will, but I'm not
complaining about anything that you liekly have skin in unless you wrote
the build system that produced the endeca build and/or all the other builds
that produced the binaries that are included in it.

> 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
> when building and I asked whether the libraries had DT_SONAME (and give
> you the readelf
> command to verify.
I very clearly stated that, while it might not be wrong, it wasn't
producing what was desirable for my end-result.

> > 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.
I apologize for not understanding what you're saying here.  Once again, if
I understand you correctly, you seem to think that I compiled this code
somewhere along the line.  I did not.  It is a commercial product,
distributed with an installer, that I'm simply attempting to shoehorn into
an RPM.  I have precisely no visibility into nor leverage on the supplier
and, frankly, wouldn't want any.  I might get something on me that would be
difficult to clean off. :)

> > 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.
How clever!

That was written not out of a call for sympathy but to indicate what I
experience in the wild in the hope that it would illuminate this as an
increasing problem.  It's not the responsibility of rpm to make people
package code correctly.  That's a human process problem.  It's just one
that seems to be getting worse instead of better.  Also, while I enjoy
unnecessary dickishness as much as the next child of the information age,
it's probably not an appropriate response here barring a 299.80 diagnosis.

> > 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.

I'm trying to do that, but I actually don't understand what you're saying
here.  In my head, it sound like you're whingeing, but that doesn't seem
like something reasonable to do.  Could you clarify?  Or, more likely, the
email that I'm sending you (noted below) will possibly answer your question.

> > 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!

It is my plan to do so.

> > 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?

I think it's OK to do this, but I'm going to do so directly to your
personal email so that I don't display piles of potentially litigious data
in a public forum.

Received on Sun Jan 6 21:34:55 2013
Driven by Jeff Johnson and the RPM project team.
Hosted by OpenPKG and Ralf S. Engelschall.
Powered by FreeBSD and OpenPKG.