RPM Community Forums

Mailing List Message of <rpm-users>

Re: rpm on OSX Lion

From: Henri Gomez <henri.gomez@gmail.com>
Date: Sun 25 Mar 2012 - 17:18:16 CEST
Message-Id: <478B7DFF-D109-424E-B3F9-7069D243EAA3@gmail.com>
First thing I'd like to do is building RPM 5.x from tarball or SCM with no dependencies on MacPorts. 

Advices very welcomed :-)

If build scripts are available I'll study them closely. 

Le 25 mars 2012 à 14:33, Jeffrey Johnson <n3npq@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
Received on Sun Mar 25 17:43:59 2012
Driven by Jeff Johnson and the RPM project team.
Hosted by OpenPKG and Ralf S. Engelschall.
Powered by FreeBSD and OpenPKG.