On Mar 25, 2012, at 11:18 AM, Henri Gomez wrote:
> First thing I'd like to do is building RPM 5.x from tarball or SCM with no
> dependencies on MacPorts.
Here's the build incantations:
$ cvs -d ':pserver:anonym...@rpm5.org:/v/rpm/cvs' get -r rpm-5_4 -d wdj54
rpm
$ cd wdj54
$ ./devtool checkout
$ ./devtool falmouth
$ make
$ cd tests
$ make clean test
You WILL need (on Lion) to install db-5.3.15 (I'm told that a db53 port was
just added).
I do this one expedient hack with db-5.,3.15 (because its a PITA to "fix"
properly):
cd /opt/local/lib
ln -s db53/* .
Change the %falmouth stanza to lose any build prerequisites
(mostly bog standard MacPorts but I do what is needed to
enable _EVERYTHING_ for RPM development) that you do not wish to fight with.
>
> Advices very welcomed :-)
>
> If build scripts are available I'll study them closely.
>
The build scripts above are all that is needed. What is harder is ensuring
all the build prerequisites are in place and choosing the build options.
The above is essentially what is running in the LION_rpm_rpm54 waterfall.
Examine those builds to see what is needed.
Building RPM is _NOT_ as simple as doing
./configure --prefix=/usr
which everyone expects.
The "./devtool …" paradigm is based on GNU shtool.
Another piece of RPM's build puzzle is a very slick
RPM_CHECK_LIB()
m4 macro that Just Works in most cases (note: that it took me
more than a year to learn how to use RPM_CHECK_LIB() and
'm still learning tricks and twists even today …)
Both devtool and RPM_CHECK_LIB are from Ralf S Engelschall
at OpenPKG: _REALLY_ nicely done engineering imho.
hth
73 de Jeff
> Le 25 mars 2012 à 14:33, Jeffrey Johnson <n3...@me.com> a écrit :
>
>>
>> On Mar 25, 2012, at 2:59 AM, Henri Gomez wrote:
>>
>>>> Jenkins is spiffy, buildbot -- particularly with older python-2.4 --
>>>> is a bit of wrestling match.
>>>>
>>>> I set up both on the same machine. Jenkins/Hudson needed
>>>> 500 Mb and filled /var/log within a week with useless messages.
>>>
>>> Yep, Jenkins could be very verbose, but well, it fit well Continuous
>>> Integration need (more than just a build engine).
>>> And I'm pretty experienced with it :)
>>>
>>
>> Either Jenkins/Hudson or buildbot are adequate to my usage case.
>>
>> Yes more than a "build engine is needed". Note that "de facto" CI in
>> RPM is currently using OWL2/OWL3/IDMS (because those
>> distros are small and the packaging has few errors), installing into
>> a chroot, and undertaking packaging QA (and explicit code coverage
>> of common "production" RPM code paths).
>>
>>>> Buildbot is lighter weight and sooner or later one figures
>>>> out the double half nelson hammerlock to pin buildbot in
>>>> the wrestling match of CI.
>>>
>>>>
>>>> You want a full distro on Mac OS X based on RPM? Count me in …
>>>
>>> I'd like to. May be it's covered by OpenPKG project ?
>>
>> Yes OpenPKG runs on Mac OS X. But the OpenPKG approach
>> is running on multiple platforms reliably in a *BSD jail. That's
>> very different than a MacPorts or Homebrew replacement.
>>
>>> BTW, we are many tired to see MacPorts or Brew requiring to download
>>> all internet and build it locally.
>>> There is a strong interest for RPMs on OSX.
>>
>> Well … maybe. There is interest in RPM on Mac OS X this week, not
>> just from you. The interest historically has been in binary packages,
>> not in RPM (which has been available in MacPorts and *BSD thanks
>> to Anders Bjorkland for years).
>>
>>>
>>>>> I tried to build various versions of rpm but they required beecrypt and
>>>>> popt.
>>>>
>>>> Yes: neither bee crypt nor popt is optional. Both are distributed with
>>>> RPM "batteries included".
>>>
>>> What do you means by RPM batteries included ?
>>
>> I meant 2 things:
>>
>> 1) This is a whole lot of "batteries" (i.e. libraries) linked into
>> an ELF executable:
>> $ ldd .libs/rpm | wc -l 92
>>
>> 2) The AutoFu is unusual because RPM supports -with-foo=internal
>> for libraries that are problematic. All of the build problems you reported
>> Berkeley DB
>> BeeCrypt
>> popt
>> are problematic for different reasons. When RPM is built "batteries
>> included",
>> your problems building RPM pre-requisites case to exist: those libraries
>> are built with RPM and are installed with RPM in -lrpmmisc.
>>
>>> beecrypt and popt are reported mandatory in 5.x release (from what I
>>> see in configure).
>>>
>>
>> Yes: common digests are computed by BeeCrypt and option processing
>> is perfumed by popt. RPM has used bee crypt and popt since forever.
>>
>>>>> My Lion machine is using 64bits kernel and I can't succeed build
>>>>> beecrypt in universal mode (32/64 bits) ;(
>>>>>
>>>>
>>>> Beecrypt ends up in -lrpmmisc if building
>>>> --with-beecrypt=internal
>>>
>>> beecrypt internal means it will be build statically in rpm ?
>>
>> Not "statically" but otherwise yes.
>>
>>> So beecrypt lib sources should be included somewhere I guess
>>>
>>
>> Beecrypt (and popt) sources are added to RPM's build tree by
>> ./devtool checkout
>> when building from CVS. And a concept of a tar ball release isn't
>> all that useful because on set of files needs to be chosen for distribution.
>>
>> E.g. Berkeley DB isn't (currently) being distributed within RPM tar balls
>> largely because I got tired of hearing Bloat! Bloat! Bloat!. The cost
>> of a smaller tar ball is that the build is harder: detecting/linking all
>> possible
>> versions on all possible platforms for BDB is exactly one of the problems
>> that
>> you (and others) are reporting.
>>
>> So the choice in RPM is
>>
>> 1) distribute RPM+BDB and build internally and users complain about Bloat!
>> 2) target a single version of Berkeley DB external installed one specific way
>> and users complain about hard to build.
>>
>>>>> So I'd like to avoid requiring MacPorts but it seems we need many
>>>>> bootstrap libraries like popt/beecrypt (and in Universal Format).
>>>>
>>>> Only if you choose to build against external libraries. E.g. Berkeley DB
>>>> can be built and distributed with RPM as well. In fact that is what I
>>>> would do if the decision was mine: writing AutoFu tests for all possible
>>>> versions of Berkeley DB is much harder than just bundling Berkeley DB
>>>> within RPM (as was done for years).
>>>
>>> +1 for embebed Berkeley DB inside RPM, there is just too many versions
>>> on BDB around and it could be a nightmare.
>>>
>>
>> Sadly votes and opinions and engineering do not matter: building RPM
>> with BDB externally (and cutting the size of the distributed rpm-X.Y.Z.tar.gz
>> by more than 50%) was hugely popular.
>>
>> Meanwhile, if you untar db-5.3.15.tar.gz in the top level directory,
>> and rename to "db", you likely have a pretty good chance that
>> internal Just Works (but there are other and more complex issues
>> with embedded sqlite3)
>>
>>>> What is involved with "Universal Format" for you?
>>>
>>> OSX could build it binaries including many formats, aka x86 32bits and
>>> x86 64bits.
>>> Take a look here, I detail build process for mod_jk in dual model mode :
>>>
>>> http://blog.hgomez.net/2012/03/21/building-universal-apache-tomcat-connector-mod_jk-on-osx/
>>
>> If you give me an example of the exact commands needed to make
>> some simple build (like popt or GNU time) "universal", I can likely
>> make that happen with BeeCrypt.
>>
>> But I think the need for "universal" support in RPM is in recipes,
>> not in RPM's own build pre-requisites.
>>
>> hth
>>
>> 73 de Jeff
>>> ______________________________________________________________________
>>> RPM Package Manager http://rpm5.org
>>> User Communication List rpm-users@rpm5.org
>>
>> ______________________________________________________________________
>> RPM Package Manager http://rpm5.org
>> User Communication List rpm-users@rpm5.org
> ______________________________________________________________________
> RPM Package Manager http://rpm5.org
> User Communication List rpm-users@rpm5.org
______________________________________________________________________
RPM Package Manager http://rpm5.org
User Communication List rpm-users@rpm5.org
