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:anonym...@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

Reply via email to