On Mar 26, 2012, at 11:48 AM, Henri Gomez wrote:
>> But see the options use when db-5.3.15 is built. This
>> is what I use to build Berkely DB on Mac OS X (after
>> creating a build_macosx directory to build in)
>> ===================
>> #!/bin/sh
>>
>> prefix=/opt/local
>> configure_cmd="../dist/configure"
>> configure_args="
>> --prefix=${prefix}
>> --enable-cxx
>> --enable-java
>> --enable-sql
>> --includedir=${prefix}/include/db53
>> --libdir=${prefix}/lib/db53
>> --program-transform-name=s,^db,db53,
>> --enable-tcl
>> --with-tcl=${prefix}/lib
>> "
>>
>> $configure_cmd $configure_args
>> ===================
>
> Ok, I'll compare.
>
>> BeeCrypt was heavily used in Java long ago: dunno if still useful.
>> RPM doesn't need/use.
>
> So no need for me to support Java for bee crypt :)
>
>>> Any suggested macros for OSX ?
>>
>> OSX has a "fat" architecture that is essentially the same as "noarch".
>> EVeryone invents new names and the diversity just confuses.
>
> True ;(
Use "noarch". What would be kinda spiffy is to automate lipo
under RPM control and strip out the unused architectures
in universal executables (and if one "trusts" the automated dependencies
are accurate) the libraries.
I've also been waiting (like 8 years now, sigh) to internalize MACH-O
like ELF in RPM. Using "helper" scripts like find-requires/find-provides
is fine of now, but an implementation in C is precise and accurate
and maintainable in a way that scripts will never be.
>
>> The default macros SHOULD be gud enuf on Mac OS X.
>
> Perfect
>
>> Anders Bjorkland's Mac OS X distro based on RPM is still likely
>> the best around.
>
> This one (http://www.algonet.se/~afb/rpm/) ?
>
That's the one. There's another RPM based distro in Japan
from a physics lab that might by useful too.
>> Not sure what you ask here: you want a rpm-mac mailing list?
>
> Nope, I just want to see if there is other guys interested with RPM on OSX.
> Frankly, I'm borred to rebuild Brew/MacPorts stuff and I'm not alone.
> I just want to be able to set a package repository and use yum or
> zypper to get stuff downloaded and installed.
>
Boredom well understood. Last night I was trying to install
ODBC -> postgres for something I was doing. I typed
port selfudate
port upgrade outdated
(which I tend to do lazily when needed, like semi-monthly) and suddenly
I have a pile of builds that I have to wait out before resuming what
I needed to do.
I went out for sashimi and went to bed instead. ;-)
The point is this:
The *BSD "make world" paradigm doesn't scale.
Note that I'm an old school *BSD guy, and actually _like_
the "make world" paradigm when I'm developing. But RPM
binary packaging beats the crap out of maintaining huge
complex source dependencies: its all to easy to get sucked
into some black hole of fixing.
Re package repositories:
If you point me at some set of binary *.rpm packages that has
dependency closure, I will quickly attempt installing those
in the Lion waterfall at
http://harwich.jbj.org:8010/waterfall
All I need is a manifest of URI's to a set of packages. There
are 2 pattern rules in tests/Makefile.am to do
make Install-FOO
make Verify-FOO
Yesterday it took all of 15 minutes (once I was given a manifest
of package URI's) to wire up Alt Sisyphus and succeed (modulo
--nodeps: Alt has something called a "set-version" dependency
that I am currently porting) … to succeed in creating a chroot.
I'm quite sure that I can find packaging flaws faster/better with
make Install-FOO
make Verify-FOO
explict testing than any amount of packaging QA.
>> Or are you referring to Anders (who knows way more about RPM
>> on Mac OS X than anyone else, with many other skills ;-)
>
> If there is a RPM DMG available right now for Snow and Lion, with a
> stable RPM, I'll be happy to use it.
> Then we could works on building a community for RPMs production :)
I will host (because I will need it for build slaves) a repository for mac os x.
(aside)
ANd as you proceed using rpm-5.4.x, I'm quite likely going
to need a build configuration from you running in a buildslave
to ensure that I don't screw something in RPM: I expect some
very aggressive "features" (like RPM+GIT, RPM+SVN, RPM+ODBC
and those Alt
Requires: set:qerkjherlkh
dependencies and more) to be available as I proceed.
Whether the buildslave runs on your host or mine, what is needed
near term is a set of build options you wish to use.
E.g. you haven't enabled bzip2/xz compressions (LZO might be
implemented in RPM too, I forget), and _SOME_ embedded language
is almost essential (lua is quite stable, perl is likely quite useful).
Note also some useful tools, specifically tools/mtree, which can be
run on a remote ftp/http tree and generate a manifest with URI's instead
of paths, that are quite "natural" to use on Mac OS X (and were
tested to interoperate with the "system" mtree)
Caveat:
I haven't looked at mtree recently. And you will need neon
to access remote URI's. Well duh ;-)
>
>> Anders is part of the @rpm5.org project: maintains the MacPorts
>> and FreeBSD ports, "smart" guy too ;-)
>
> It seems to be the 'OSX/RPM guru' so willing to heard more from him :)
In case you missed the pun:
Anders also maintains the smart package manager, which is likelier
to Just Work with @rpm5.org than yum/zypper (or urpmi) atm.
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
