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 <firstname.lastname@example.org>:
> 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@example.com:/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".
> 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
> 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
> 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:
> and today
> RPM + version-sets
> 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.
> 73 de Jeff
> RPM Package Manager http://rpm5.org
> User Communication List firstname.lastname@example.org
Received on Sun Mar 25 22:39:18 2012