On Jun 27, 2011, at 10:11 AM, Sriram Narayanan wrote:
> Hi Jeff:
>
> Some questions below:
>
> On Mon, Jun 27, 2011 at 7:30 PM, Jeff Johnson <n3...@mac.com> wrote:
>
>
>> There is no simple solution that I see to the above: either more resources
>> @rpm5.org
>> are needed (which is unlikely to happen), or users are going to have
>> to patch the released version to accommodate their own specific build needs.
>>
>
> What are these resources ? People or computers ?
>
Interest mostly. Its utterly trivial to find hardware assets,
just the sysadmin maintenance and QA is already eating up
2-3 weeks per month of my time doing tedious "due diligence".
I can't justify that time expenditure any further.
>> The necessary changes are not all that hard:
>>
>> There are two places that
>> #include <db51/db.h>
>> is used that need to be changed. Its the "db51/" portion
>> of the include that causes build failures.
>>
>
> You've answered this before, but could you please tell us once again
> what would be the repercussions of changing this to
>
> #include <db.h>
>
That *is* what should be done. Adding any sort of hierarchical
structure to #include's causes issues. E.g. building rpm from
a cvs checkout with
#include <rpm/rpmlib.h>
is impossible because of the name collision on "rpm". Sure
the problem could be "fixed" by rearranging how directories
in RPM sources (in CVS) are created. But the general fix is
Never do
#include <foo/bar.h>
Always add ""-I/prefix/some/where/include/foo" to CFLAGS and
#include <bar.h>
Anyways I'm well aware of the problem, there's a snarl of build
issues conflicting with features related to
Which sqlite should be used: from db-5.x.y or external?
that instantly appear if you try
#include <db.h>
Been there, done that, wrestled for a month last September with
the issues that cannot be resolved until
Should rpm embed sqlite? How?
have clearer answers.
>> And there are these 3 approaches to building RPM:
>>
>> 1) install db-5.1.x into
>> /usr/include/db51/db.h
>> /usr/lib/libdb-5.1.*
>
> The default make install for bdb creates some other folder structures.
> I've had to symlink from those locations to the above.
>
Yup. Everyone does things differently.
FYI: The *.spec I use on other platforms that do not have
Berkeley DB db-5.1.x is available by checking out the top
level "distro" module from @rpm5.org cvs. Download the necessary
"official" release tar ball's from Oracle and build. WORKSFORME
almost everywhere (though I somethings have to adjust paths to
accomodate uglix vendor divergence: *BSD tends to choose different
paths than linux does hysterically while installing Berkeley DB).
>>
>> 2) patch RPM to use a different version of Berkeley DB
>>
>> 3) re-add Berkeley DB db-5.1.x internal to RPM.
>>
>
> What is the reason that you'd removed this ? How about making this the
> default again, with us distro folk having to explicitly specify
> --with-db=external ?
>
The positive justification for removal is
The released tar ball is >50% smaller without Berkeley DB included.
Sure I can flip … flop … flip … flop … forever. I have gone along
with the de facto chosen conventions of
Always use system Berkeley DB.
largely because its a waste of time to continue the discussion.
If the choice was up to me, I'd _ALWAYS_ embed Berkeley DB everywhere
needed. Meanwhile I don't care to endlessly restate my engineering reasons to
linux "community"advocates that just want to chant
Bloat! Bloat! Bloat! Bloat! Bloat! Bloat!
in spite of what is recommended by Oracle (nee Sleepycat) for >10 years.
>> @rpm5.org cannot dictate which of those approaches end-users wish to choose
>> in RPM.
>>
>
> I feel that getting rpm5 to build easily is a good goal to have. I've
> learned that if I read your INSTALL document, and then follow
> devtool.conf, then life becomes easier.
>
The flaw here is that RPM has a whopping amount of
Have it your own way!
flexibility. SO there's insufficient context to define "easily"
meaningfully, there's already a combinatorial failure of the
dozens of build options that cannot ever be properly tested
(even if there was a desire to do so).
E.g. its quite possible to build RPM "easily" with
no database support
no compression support
no crypto digest support
and have an utterly useless executable that "builds easily".
Please note that I'm _NOT_ disagreeing with the goal. Just that
how rpm builds is way way way too complex, and its the
Have it your own way!
complexity that needs to be ripped out imho, not made Yet More Adaptable!
73 de Jeff______________________________________________________________________
RPM Package Manager http://rpm5.org
User Communication List rpm-users@rpm5.org
