On Fri, Jun 29, 2007, Tim Mooney wrote:

> In regard to: No Neon patch..., Mark Hatle said (at 1:22pm on Jun 29,
> 2007):
>
>> Taken from rpm.org rpm-4.4.2.1 tree.
>>
>> Any comments or may I commit.  (I didn't just hit go, since I figured
>> there might be some "discussion" on this issue.)  :)
>
> neon can be a PITA, especially because it defaults to static lib only
> and has non-obvious dependencies so linking with it can be challenging,

The new RPM_CHECK_LIB leverages Neon's neon-config(1) and neon.pc
pkg-config(1) files which output the dependency libraries just fine
under "neon-config --libs" and "pkg-config neon --libs" for me. So, this
at least should be not big issue for RPM any longer.

> [...]
> I know I'm frequently in left field WRT rpm, but I think if you make
> stuff like neon or lua too easily "optional", those things will fall
> outside of the minimal subset, and at that point one needs to decide if
> it wouldn't be better to just remove the evolutionary leftovers
> completely.

Yes, fully valid argumentation.

At least for world of Linux distributions where at least in theory
one could have a single third-party RPM package which is intended for
installation on _different_ Linux distributions. Here, as you argue
correctly, an RPM which is built differently on each Linux distribution
makes great problems, of course. But IMHO in practice this problem
isn't such large as for lots of other reasons one already cannot
easily deploy arbitrary RPM packages on arbitrary RPM based Linux
distributions. Usually the packages are dedicated for a _particular_ RPM
based distribution and then the drawback of varying RPM functionality
isn't such a big problem.

Sidenote: this is a little bit similar to the discussion we had about
10 years ago in the Apache HTTP server project when we introduced the
possibility to enable/disable modules during build-time and then even
the possibility to dynamically load additional modules under run-time.
Many people said this will make Apache totally useless in practice as
it longer is a well-defined webserver platform and some even said this
flexibility will in the long-term be the death of Apache. Well, perhaps
this "long-term death" is true, but as it looks Apache at least requires
another whole decade to die _this_ way ;-)

Nevertheless, I agree with you: flexibilities like this have their
cost. The question is just whether the advantages more balance the
disadvantages.

                                       Ralf S. Engelschall
                                       rse@engelschall.com
                                       www.engelschall.com