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
