RPM Community Forums

Mailing List Message of <rpm-users>

Re: rpm on OSX Lion

From: Henri Gomez <henri.gomez@gmail.com>
Date: Sun 25 Mar 2012 - 22:39:16 CEST
Message-ID: <CALyUpY29ZmcTkmFryhuZLdpGwffdsjFDesR5KzR3_W-QR8f4dg@mail.gmail.com>
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 <n3npq@me.com>:
> 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:anonymous@rpm5.org:/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                             rpm-users@rpm5.org
Received on Sun Mar 25 22:39:18 2012
Driven by Jeff Johnson and the RPM project team.
Hosted by OpenPKG and Ralf S. Engelschall.
Powered by FreeBSD and OpenPKG.