You're amazing guys ! Well, I feel I have works-fun next week.
I'll avoid /opt of course, first step will be to install rpm under /usr/bin for a test drive and test some of my own rpms. If it works great, next step may be a relocation under /opt/rpm4osx or something like this, ie using a specific bin/lib paths for packages (like MacPorts/Brew does). I now some guys who'll be happy to get a rpm based way to get packages installed via yum for example. Stay tuned, I'll probably ask you more questions in a very near futur. Long live RPM ! :-) 2012/3/25 Jeffrey Johnson <[email protected]>: > > On Mar 25, 2012, at 1:07 PM, Anders F Björklund wrote: > >> Jeffrey Johnson 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:[email protected]:/v/rpm/cvs' get -r rpm-5_4 -d wdj54 >>> rpm >>> $ cd wdj54 >>> $ ./devtool checkout >>> $ ./devtool falmouth >>> $ make >>> $ cd tests >>> $ make clean test >> >> Installing things, not managed by MacPorts, into the "/opt/local" prefix >> is bound to cause some conflicts one way or another. Wouldn't recommend it. >> > > Yes: when the content collides port(1) whines. Meanwhile, I > can/will revert my builds lave hacks as MacPorts "catches up". > > (aside) > All of the *BSD distros are surprisingly up to date. E.g. I was > surprised to see libgit2 appear in MacPorts out of nowhere > a coupl;e weeks back. Just seeing libgit2 adoption _SOMEWHERE_ > was enough to increase my interest. Otherwise its just Yet Another > Battle of irrelevant software from linux distros that are increasingly > unwilling to update and maintain (and with libgit2: augment) their > Pwecious Wepositowies > >>> 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/* . >> >> It should be enough to use the regular CPPFLAGS+=-I/opt/local/include/db53 >> and LDFLAGS+=-L/opt/local/lib/db53, rather than setting up symlinks, I think. >> > > Quite easy for a human yes. OTOH, buildslaves require 100% fully automated > builds, and that last 0.00001% is exceptionally painful to deploy. > > E.g. I (and with help from you ;-) have wasted days just trying to get > the AutoFu in place to find what used to be a very simple and common > uglix path > /etc/magic > and which is now installed on some path that correlates with > almost nothing sane. > >>> 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. >> >> Adding a "rpm54" port would be the most straight-forward way to include it. >> I'll see what I can do about it, should be a copy of the existing "rpm52"… >> > > I'd be a bit lazy about rpm54 which is quite "active" atm. Meanwhile, > rpm-5.3.11++ is "production" and "stable" and all that good stuff. > >> >> Of course, neither the %falmouth nor the (post-5.2) %macosx devtool target >> nor the mac ports will help if one wants to make a stand-alone distribution. >> > > I still prefer > --prefix=/usr > on Mac OS X just because its KISS. There's literally no reason for > multiple interoperable versions of RPM unless one wants to > have a FUD fight with the Script Kiddie in the cafeteria for some reason. > >> Then you need to start from the beginning, by installing all dependencies. >> Just like the %standalone target used to do, while it was still "alive" ? >> > > The %standalone could be dusted off and resurrected and even attempted > in builds laves if there was interest. > > Just that RPM's "feature set" is growing rapidly and there isn't any > sense of sanity any more. > > Note all of these fairly aggressive "features" in rpm-5_4: > RPM+GIT > RPM+ODBC > and today > RPM + version-sets > (aside) > Alt has dependencies (and a rpmlib(SetVersions) tracking dependency: eeek!) > that look like this: > > Unsatisfied dependencies for librpm-4.0.4-alt100.48.x86_64: > Requires: ld-linux-x86-64.so.2()(64bit) >= set:ihidc > Requires: libbeecrypt.so.7()(64bit) >= > set:mhhDthCzKb1jmWTlFex3hTP1fZ9qdjdg5R0Ki9ZGsyUwKAWfS > Requires: libbz2.so.1()(64bit) >= set:ifKTc38cpjCTVElPz9 > Requires: libdb-4.7.so()(64bit) >= set:jgqkEXaUzonx2 > Requires: libelf.so.1()(64bit) >= set:kgwCsW8ZzioOVCwIkTfY6HIZl1 > Requires: liblzma.so.5()(64bit) >= set:khmhwPSISTidIxcswe > Requires: libpopt.so.0()(64bit) >= set:ihGO1 > Requires: libselinux.so.1()(64bit) >= set:lh0RFVmZz943Uzb6j7vuSMCo1 > Requires: libz.so.1()(64bit) >= set:kg0hJg923EZ3mQTTIo11VHd > … > > I'm sure you recognize base62 encoding when you see it ;-) > > I haven't a clue what Alexey Tourbin did (well I know conceptually) yet. > > I'm hoping to get the set-version functionality in place to feed Sisyphus > "sausages" > to the hungry buildslaves waiting to do > cd tests > make Install-ALT51 > make Verify-ALT51 > I'll add test/ref/alt-minimal.x86_64.manifest in case you want to try-and-see > some "wild hacking" that just started this morning. > > Meanwhile back to RPM+ODBC (and in JavaScript next ;-) > > hth > > 73 de Jeff > > ______________________________________________________________________ > RPM Package Manager http://rpm5.org > User Communication List [email protected] ______________________________________________________________________ RPM Package Manager http://rpm5.org User Communication List [email protected]
