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 <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
