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 <firstname.lastname@example.org> 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
> 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
>> 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 :
> 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.
> 73 de Jeff
>> RPM Package Manager http://rpm5.org
>> User Communication List email@example.com
> RPM Package Manager http://rpm5.org
> User Communication List firstname.lastname@example.org
Received on Sun Mar 25 17:43:59 2012