pacman on OSX (again!)

lloeki · 2008-08-23 15:38:33

Hello again, fellow archers! I've not posted nor monitored arch-related stuff for quite some time, because I moved to MacOSX...

In the process I began looking for some nice package management system for OSX, at least for command line stuff. I obviously found about fink, macports, and gentoo/alt. problems: fink just sucks and has massively outdated packages, gentoo/alt is out of question (I moved away from gentoo for a reason!), and macports is good, but does some things just stupidly (try to install ikiwiki, just for a laugh), and has outdated packages, and is a pain to use, and is not KISS, and... well, I just love pacman/abs.

so I went on a journey to see what I can do about it.
given that pacman is so KISS, it has few deps. therefore compiling it on mac should be easy.

first, of course I downloaded xcode 3.1 from apple dev.

I then fetched libarchive, libdownload and pacman source tarballs.

libarchive built easily:

tar xvfz libarchive-2.5.5.tar.gz
cd libarchive-2.5.5

./configure --prefix=/opt/arch/usr
make
sudo make install

libdownload chokes on libio.h therefore I disabled pacman internal download with configure. Aaron mentioned some OSX branch, but I can't seem to find anything. well, whatever. I then had some trouble with configure/make not finding libarchive libs/headers easily in its special location, and a few env vars did the trick:

tar xvfz pacman-3.2.0.tar.gz
cd pacman-3.2.0

./configure CPATH=/opt/arch/usr/include LDFLAGS=-L/opt/arch/usr/lib --disable-internal-download --prefix=/opt/arch/usr --with-root-dir=/opt/arch

make CPATH=/opt/arch/usr/include LDFLAGS=-L/opt/arch/usr/lib

sudo make install

on to test the thing:

$ /opt/arch/usr/bin/pacman -V

 .--.                  Pacman v3.2.0 - libalpm v3.0.0
/ _.-' .-.  .-.  .-.   Copyright (C) 2006-2008 Dan McGee <dan@archlinux.org>
\  '-. '-'  '-'  '-'   Copyright (C) 2002-2006 Judd Vinet <jvinet@zeroflux.org>
 '--'
                       This program may be freely redistributed under
                       the terms of the GNU General Public License.

woohoo.

I guess I'll then have to change the XferCommand in pacman.conf, because it's set to use wget, and only curl is there in a raw OSX system.
After that I'll obviously have to create some OSX specific PKGBUILDs+abs repo+binary repo because things don't match (arch)linux ones in so many areas... long, tedious work, but for now I do it for fun, so I'll just concentrate on software I use. this is mostly private work for now, but I felt like documenting this could be useful to some people at some point.

cactus · 2008-08-23 18:43:54

try it with libfetch instead of libdownload. You can install libfetch from macports (I think). I know pacman built just fine with libfetch on freebsd the last time I tested it (with some help from Dan).

shining · 2008-08-23 22:14:16

I would suggest reading this thread :
http://www.archlinux.org/pipermail/pacm … 11916.html
And eventually getting in touch with Xilon,

Edit : pacman 3.2.0 should indeed build fine against libfetch thanks to Dan
And thanks to Xilon, makepkg and repo-add 3.2.0 contain many BSD/OSX portability improvements.

Last edited by shining (2008-08-23 22:16:04)

Lord Illidan · 2008-08-23 22:51:17

Oh well..this has removed the last obstacle from my future migration to OS X. All hail Steve Jobs and the mighty Lloeki!

lloeki · 2008-10-30 08:17:02

still on the job.

now I've got fakeroot working correctly on macosx

I have some trouble still. it seems makepkg drops any arguments passed to it. really weird bug, and a showstopper.

shining · 2008-10-30 08:48:57

lloeki wrote:

still on the job.
now I've got fakeroot working correctly on macosx
I have some trouble still. it seems makepkg drops any arguments passed to it. really weird bug, and a showstopper.

Check this thread :
http://www.archlinux.org/pipermail/pacm … 12047.html

You should try to write some gnu getopt detection code to find the path to gnu getopt, using getopt -T.
Test that it works correctly on linux and bsd, then submit it to pacman-dev ML

lloeki · 2008-10-30 17:46:51

thanks a lot. I guess I'm not too much into MLs...

browsing the thread you mentioned, I found this one which is on the issue, but no followup since may. http://www.archlinux.org/pipermail/pacm … 11830.html

btw on OSX there's no GNU getopt by default, so you have to rely on third party install. I'll try to build it from util-linux and see if that works as a replacement.

my goal here is to have a pacman-based system with the minimum set of dependencies and redundancy with OSX provided tools. I'll see what I will come up as a solution.

Last edited by lloeki (2008-10-30 17:51:45)

phrakture · 2008-10-30 18:19:25

I'm interested in this too. Using pacman as an alternative to MacPorts would be fun.

Additionally, if someone wants to be sassy, the same thing under cygwin would be awesome too. arch=(i686 x86_64 mac win32)

lloeki · 2008-10-30 18:28:28

in fact, arch=(i386) under OSX
at least that's what makepkg wants from a PKGBUILD OOTB.

BTW I noticed that (from makepkg)

OPT_TEMP="$(getopt -o "$OPT_SHORT" -l "$OPT_LONG" -n "$(basename "$0")" -- $* || echo 'GETOPT GO BANG!')"
if echo "$OPT_TEMP" | grep -q 'GETOPT GO BANG!'; then
    # This is a small hack to stop the script bailing with 'set -e'
    echo; usage; exit 1 # E_INVALID_OPTION;
fi
eval set -- "$OPT_TEMP"

vs (from BSD man getopt(1))

args=`getopt abo: $*`
           # you should not use `getopt abo: "$@"` since that would parse
           # the arguments differently from what the set command below does.
           if [ $? != 0 ]
           then
                   echo 'Usage: ...'
                   exit 2
           fi
           set -- $args
           # You cannot use the set command with a backquoted getopt directly,
           # since the exit code from getopt would be shadowed by those of set,
           # which is zero by definition.

note the first comment. maybe not related to the current issue, but hey, it made me raise an eyebrow.

Last edited by lloeki (2008-10-30 18:30:32)

lloeki · 2008-10-30 20:50:35

completely hackish for now, but I altered a PKGBUILD to successfully build gettext, which is required to build GNU getopt, for which I made a PKGBUILD too (standalone one, not from util-linux, although they're in sync).

makepkg now parses arguments correctly, and fakeroot works (since it failed to enter the fakeroot because it failed to add --asroot).

as a consequence, both the package manager and the package building environment are autonomous. in other words, I bootstrapped arch on osx!

I still need to do some cleanup here and there (notably un-hardcode some stuff, create patches, etc...) before sharing it, but it works nicely. seems ridiculous but I can't help but feel happy about having successfully put this together. now I should really put that stupid grin off my face

Last edited by lloeki (2008-10-30 20:53:38)

toofishes · 2008-10-31 01:31:26

I'd really prefer to keep most of this talk on the ML, but looking through that thread link it was leading to a bit of a bikeshed- "let's drop long opts because of incapabilities of getopt on other platforms". That is a pretty weak argument.

I'm all in support of a patch to fix this, but I don't think changing our options list to accommodate deficiencies is the best way to approach it.

lloeki · 2008-10-31 11:04:15

I'm all in support of a patch to fix this, but I don't think changing our options list to accommodate deficiencies is the best way to approach it.

indeed. that's why I went the straight way and built GNU getopt. IMHO any worthy makepkg patch should be able to handle longopts. the thread shining digged up raised interesting points on that matter. the one I digged up was more for the sake of completeness to the discussion. anyway, I don't feel confident enough to write such a patch and - since I have the easy GNU getopt solution - it feels a bit out of the scope of my little experiment.

that said, I have a number of interesting issues here. pacman's configure --with-root-dir is good, but ahs some side effects later. here I configured pacman --with-root-dir=/opt/arch. now I built some package (gettext) which has a .dylib (.so on osx), and another one which uses it (getopt). both have in their PKGBUILD a prefix so that things end up in pkg/usr/{bin,lib,whatever}. thus upon installation, everything goes well and ends up in /opt/arch/usr/{bin,lib,whatever}. but when running getopt, it requires the dylib and fails to load it, since it looks for it in /usr/lib (which is what has been told to configure, in order to achieve the above scheme).

possible solutions TTBOMK:
1. make pacman's root-dir / and chroot to /opt/arch
2. make pacman's root-dir / and hardcode prefix as /opt/arch in every PKGBUILD (which are osx-specific anyway)
3. export DYLD_LIBRARY_PATH=/opt/arch/usr/lib in .profile

current analysis:
1. this requires a full-blown set of packages in the chroot already provided by osx and isolates it from the rest of the system.
2. this requires everything to go into /opt/arch and nowhere else (e.g if the user wants it elsewhere)
3. I'm currently using this because it's hell of much simpler, but I don't know if it'll have adverse effects. this works well at run-time, but not at compile time: I still have to have /opt/arch in some places (-I or -L compiler flags)... maybe there's a way to un-hardcode them too? can makepkg access the RootDir setting of pacman.conf?

to illustrate the last point I have:

LDFLAGS=-L/opt/arch$(prefix)/lib -lintl

which should really look like:

LDFLAGS=-L$(RootDir)$(prefix)/lib -lintl

savvy · 2008-11-08 20:21:42

Hello,

I have been using pacman on Leopard as a replacement MacPorts for several weeks now and it works pretty well !

Anyways, I made several patches to make it work on OS X and I noticed the getopt problem is mentioned in this thread, here is my patch for makepkg.sh to make it work out of the box on OS X (without the need to install getopt).

--- scripts/makepkg.sh.in-orig    2008-10-25 16:17:48.000000000 +0200
+++ scripts/makepkg.sh.in    2008-10-25 16:19:17.000000000 +0200
@@ -762,9 +762,9 @@
         find ${STRIP_DIRS[@]} -type f 2>/dev/null | while read binary ; do
             case "$(file -biz "$binary")" in
                 *application/x-sharedlib*)  # Libraries (.so)
-                    /usr/bin/strip --strip-debug "$binary";;
+                    /usr/bin/strip -S "$binary";;
                 *application/x-archive*)    # Libraries (.a)
-                    /usr/bin/strip --strip-debug "$binary";;
+                    /usr/bin/strip -S "$binary";;
                 *application/x-executable*) # Binaries
                     /usr/bin/strip "$binary";;
             esac
@@ -1183,7 +1183,25 @@
 OPT_LONG="$OPT_LONG,syncdeps,version"
 # Pacman Options
 OPT_LONG="$OPT_LONG,noconfirm,noprogressbar"
-OPT_TEMP="$(getopt -o "$OPT_SHORT" -l "$OPT_LONG" -n "$(basename "$0")" -- "$@" || echo 'GETOPT GO BANG!')"
+OPT_TEMP="$(python << EOF
+import getopt
+
+opt_short = "$OPT_SHORT"
+opt_long = "$OPT_LONG".split(',')
+args = "$@".split()
+
+outlist = []
+try:
+    opts, args = getopt.getopt(args, opt_short, opt_long)
+    for o, a in opts:
+        outlist.append(o)
+        outlist.append(a)
+except getopt.GetoptError, err:
+    outlist.append('GETOPT GO BANG!')
+outlist.append('--')
+
+print ' '.join(outlist)
+EOF)"
 if echo "$OPT_TEMP" | grep -q 'GETOPT GO BANG!'; then
     # This is a small hack to stop the script bailing with 'set -e'
     echo; usage; exit 1 # E_INVALID_OPTION;

As you can see it uses the getopt module available in Python, which comes installed by default on OS X. I think it's a pretty good workaround as it keeps the getopt long/short options compatible.

Pacman on OS X has several other issues, what I came across so far:
1) repo-add uses md5sum, Mac OS X has md5, but the output is incompatible with md5sum. I used openssl to calculate/check the md5 hashes.
2) repo-add uses some incompatible sed regexes. Needs some minor changes to the regex
3) repo-add uses realpath, Mac OS X does not have it. readlink exists but works differently. I used an inline python workaround.
4) makepkg.conf.in, Mac OS X does not have wget. use curl instead.

If people are interested I can post my patches for these issues as well. As for PKGBUILD compatibility, I went for the '/opt/arch' prefix in PKGBUILDS, for example my gettext PKGBUILD looks like this:

<some code snipped>
prefix="/opt/arch"

build() {
  cd ${startdir}/src/${pkgname}-${pkgver}
  sed -i -e 's/libexpat.so.0/libexpat.so.1/' gettext-tools/src/x-glade.c
  ./configure --prefix=$prefix --disable-java --disable-native-java
  make || return 1
  make DESTDIR=${startdir}/pkg install
  rm -f ${pkgdir}/usr/share/info/dir

  # move install from /opt/arch/ to /
  mv $startdir/pkg/opt/arch/* $startdir/pkg/
  rmdir $startdir/pkg/{opt/arch,opt}

  [ -f $startdir/pkg/lib/charset.alias ] && rm $startdir/pkg/lib/charset.alias
}

Last edited by savvy (2008-11-08 20:27:54)

lloeki · 2008-11-09 14:29:52

interesting. I didn't use repo-add yet so I didn't run into those issues.

md5 computation seems to work fine for makepkg so I didn't worry about that.

in pacman.conf, I used

XferCommand = /usr/bin/curl %u -o %o

because the default (with >) didn't work fine.
in the same manner, in makepkg.conf I used

DLAGENTS=('ftp::/usr/bin/curl %u -o %o'
          'http::/usr/bin/curl %u -o %o'
          'https::/usr/bin/curl %u -o %o'
          'rsync::/usr/bin/rsync -z %u %o'
          'scp::/usr/bin/scp -C %u %o')

Also, I summed everything necessary to bootstrap pacman up in a Makefile:

## ArchMac pacman makefile
# (c) 2008 Loic Nageleisen
# licensed under the GPL v2


ARCHMAC_VER=0.1.0
ARCHMAC_TAR=archmac-$(ARCHMAC_VER).tar.gz

LIBARCHIVE_VER=2.5.5
PACMAN_VER=3.2.1

LIBARCHIVE_URL=http://people.freebsd.org/~kientzle/libarchive/src
PACMAN_URL=ftp://ftp.archlinux.org/other/pacman

LIBARCHIVE_SRC=libarchive-$(LIBARCHIVE_VER)
PACMAN_SRC=pacman-$(PACMAN_VER)

LIBARCHIVE_TAR=$(LIBARCHIVE_SRC).tar.gz
PACMAN_TAR=$(PACMAN_SRC).tar.gz

TARGET_DIR=/opt/arch

TMP_DIR=/tmp/archmac.tmp


all: dist


$(LIBARCHIVE_TAR):
    curl $(LIBARCHIVE_URL)/$(LIBARCHIVE_TAR) -o $(LIBARCHIVE_TAR)

$(PACMAN_TAR):
    curl $(PACMAN_URL)/$(PACMAN_TAR) -o $(PACMAN_TAR)

create_tmp:
    mkdir $(TMP_DIR)

unpack_libarchive: $(LIBARCHIVE_TAR)
    tar xvfz $(LIBARCHIVE_TAR)
    touch unpack_libarchive

configure_libarchive: unpack_libarchive
    cd $(LIBARCHIVE_SRC) && ./configure --prefix=$(TARGET_DIR)/usr
    touch configure_libarchive

make_libarchive: configure_libarchive
    cd $(LIBARCHIVE_SRC) && make
    touch make_libarchive

install_libarchive: make_libarchive
    cd $(LIBARCHIVE_SRC) && make DESTDIR=$(TMP_DIR) install


unpack_pacman: $(PACMAN_TAR)
    tar xvfz $(PACMAN_TAR)
    touch unpack_pacman

configure_pacman: unpack_pacman
    cd $(PACMAN_SRC) && ./configure CPATH=$(TMP_DIR)/$(TARGET_DIR)/usr/include LDFLAGS=-L$(TMP_DIR)/$(TARGET_DIR)/usr/lib --disable-internal-download --prefix=$(TARGET_DIR)/usr --with-root-dir=$(TARGET_DIR) --sysconfdir=$(TARGET_DIR)/etc
    touch configure_pacman

make_pacman: configure_pacman
    cd $(PACMAN_SRC) && make CPATH=$(TMP_DIR)/$(TARGET_DIR)/usr/include LDFLAGS=-L$(TMP_DIR)/$(TARGET_DIR)/usr/lib
    cat $(PACMAN_SRC)/etc/pacman.conf | sed 's-#XferCommand = /usr/bin/curl %u > %o-XferCommand = /usr/bin/curl %u > %o-' > $(PACMAN_SRC)/etc/pacman.conf.swp
    mv -f $(PACMAN_SRC)/etc/pacman.conf.swp $(PACMAN_SRC)/etc/pacman.conf
    touch make_pacman

install_pacman: make_pacman
    cd $(PACMAN_SRC) && make DESTDIR=$(TMP_DIR) install


build_all: install_libarchive install_pacman

$(ARCHMAC_TAR): build_all
    cd $(TMP_DIR) && tar cvfz $(ARCHMAC_TAR) *
    mv -f $(TMP_DIR)/$(ARCHMAC_TAR) ./

dist: $(ARCHMAC_TAR)

install:
    #tar tfz archmac-0.1.0.tar.gz | grep -v ".*/$" > installed.files
    tar xfvz $(ARCHMAC_TAR) -C /
    chown -R root:wheel $(TARGET_DIR)

uninstall:
    #cat installed.files | sed 's#\(.*\)#/\1#' | xargs rm -f
    rm -Rf $(TARGET_DIR)

clean_tmp:
    rm -Rf $(TMP_DIR)

clean_build:
    rm -Rf $(LIBARCHIVE_SRC) $(PACMAN_SRC)
    rm -f make_* configure_* unpack_*

clean_dist:
    rm -f $(ARCHMAC_TAR)

clean_download:
    rm -f $(LIBARCHIVE_TAR) $(PACMAN_TAR)

clean: clean_tmp clean_build clean_dist

clear: clean clean_download

#EOF

it lacks some stuff but should get the ball rolling for some people.

If multiple people begin to work on that I think we should begin to put some of this properly and cleanly and submit that to upstream (ML). I'm thinking mainly of non-design things things like the curl stuff, which should be set automatically when one conf/make on osx...

Last edited by lloeki (2008-11-09 14:37:01)

savvy · 2008-11-09 14:50:31

lloeki wrote:

interesting. I didn't use repo-add yet so I didn't run into those issues.
md5 computation seems to work fine for makepkg so I didn't worry about that.

makepkg uses openssl for md5 computation as well. Would make sense to patch repo-add.sh to have the same behaviour.

I have the following settings in my makepkg.conf, it mimics the original wget settings as much as possible:

DLAGENTS=('ftp::/usr/bin/curl --location --continue-at - --retry 3 --retry-delay 3 -o %o %u'
          'http::/usr/bin/curl --location --continue-at - --retry 3 --retry-delay 3 -o %o %u'
          'https::/usr/bin/curl --location --continue-at - --retry 3 --retry-delay 3 --insecure -o %o %u'
          'rsync::/usr/bin/rsync -z %u %o'
          'scp::/usr/bin/scp -C %u %o')

lloeki wrote:

If multiple people begin to work on that I think we should begin to put some of this properly and cleanly and submit that to upstream (ML). I'm thinking mainly of non-design things things like the curl stuff, which should be set automatically when one conf/make on osx...

I agree, i'm going to check out the ML right away and see if i can submit some of my patches.

btw: what do you think of the python getopt workaround on os x?

PS: seems repo-add already uses openssl now: http://archlinux.org/pipermail/pacman-d … 13018.html

Last edited by savvy (2008-11-09 14:54:35)

lloeki · 2008-11-09 15:04:38

savvy wrote:

what do you think of the python getopt workaround on os x?

in terms of workaround, it's a nice one, I didn't think of that

it troubles me though, as requiring python seems a bit excessive to me. besides 10.4 ships with python 2.3 and 10.5 with 2.5. it might get even more convoluted if one installs python via pacman. not so KISS IMHO, and too much potential points of failures.
I think requiring gnu getopt (and gettext) is better in the long run, and you seem to think the same, calling it a 'workaround'. besides, they will be dependencies of many pieces of software installed via pacman too.

the same goes for the readlink/realpath workaround.

savvy · 2008-11-17 22:39:23

I wrote a small patch to replace getopt with a bash implemention:

I posted it to the pacman ML: http://archlinux.org/pipermail/pacman-d … 13118.html

gorn · 2009-02-07 02:06:26

Just bumping this. Are people working on a MacPorts replacement based on Pacman? I'm interested in working on it, not sure if I want to lead it though. MacPorts and Fink both drive me nuts. Some kind of mac pacman would be wonderful.

tom5760 · 2009-02-07 03:53:53

I would also be interested in something like this. I agree with gorn's feelings towards MacPorts and Fink, both are pretty difficult to use.

Compiling pacman on OSX is not too difficult. Maybe I'll try to figure out how to make a OSX installer, which could install pacman, libarchive, libdownload, and fakeroot.

I suppose the next step would be to find somewhere to host PKGBUILDs, and set up some sort of 'abs' rsync mirror.

I'd be willing to try to take the lead on this. I give no guarantees on my time, but I think this could be a good opportunity for me to sorta indirectly give back to Arch.

If I get anywhere with this, I'll post back here...

EDIT:

So, I found out its really easy to build Mac installer packages, so thats not a problem.

My one issue is that I'm trying to build fakeroot, for makepkg, which I was successfully able to do, but makepkg complains about some missing symbols when you try to run it.

dyld: lazy symbol binding failed: Symbol not found: _send_get_stat64
  Referenced from: /Users/tom/prefix/lib/libfakeroot.dylib
  Expected in: flat namespace

dyld: Symbol not found: _send_get_stat64
  Referenced from: /Users/tom/prefix/lib/libfakeroot.dylib
  Expected in: flat namespace

Cant really figure it out. Fakeroot isn't really necessary, but it would make building things with the correct permissions easier.

Also, we could probably get a spot to store PKGBUILDS with something like Google Code, then we might be able to use the normal dev tools to build packages, etc.

Last edited by tom5760 (2009-02-07 05:11:37)

gorn · 2009-02-07 06:24:10

I'm having the same problem with fakeroot. Nothing showed on google so I was figuring it was something funny on my system (it's far from fresh). I'll let you know if I figure it out.

This is the list of PKGBUILD's i've done so far if you want any. Most are straight forward but some took some tricks.

cmake/ libfetch/ pkgconfig/ gettext/ libarchive/
fakeroot/ glib/ pcre/

I think something like svn would be great for the PKGBUILDs Google Code or Sourceforge would probably work. We also need to answer the question that lloeki mentioned earlier:

possible solutions TTBOMK:
1. make pacman's root-dir / and chroot to /opt/arch
2. make pacman's root-dir / and hardcode prefix as /opt/arch in every PKGBUILD (which are osx-specific anyway)
3. export DYLD_LIBRARY_PATH=/opt/arch/usr/lib in .profile

I think I prefer number 2

[edit]We have fakeroot.
It seems fakeroot gets confused about the 64bit status of Mac OS X. I put in a #if defined(__APPLE__) turn on 64 bit. Seems to be working now.
I included both the PKGBUILD/patch as well as package that you should be able to install assuming you for to the --prefix=/opt/arch method
[/edit]

Last edited by gorn (2021-02-05 19:04:51)

lloeki · 2009-02-07 11:09:22

I previously managed to fix all issues I had and successfully build and use fakeroot. In fact, the only thing I had missing is a true package tree (like abs content) specific for macosx. unfortunately that's the most time consuming part, and life has been taking most of mine (changed job, moved to another place and so on). things are still to be settling for some months, but this is a project I'd be willing to contribute to. in fact I was planning to build the equivalent of core repo, and make it available on my home server, for others to make it grow. gah, damned time, never have enough of it.

Last edited by lloeki (2009-02-07 11:09:49)

gorn · 2009-02-07 19:20:48

lloeki wrote:

In fact, the only thing I had missing is a true package tree (like abs content) specific for macosx. unfortunately that's the most time consuming part

I've been thinking about this too. It also requires some design decisions, do we install our own python? Do we try to keep the PKGBUILD's as close to Archlinux's as possible, or are we just interested in pacman? If we install with something like /opt/arch/usr so the PKGBUILD's don't need modifying for prefix, we could try to become mostly compatible with ABS and AUR packages, which would help out. (Though PKGBUILD's often use GNU install, which supports more options than Mac install, so we'd need to install coreutils and put arch ahead in the PATH. Maybe just for PKGBUILDs though and not for the user.

What unix software is everyone here interested in? I primarily had been using MacPorts for the dependencies for Player/Stage (robot control/simulation). This gives me pkg-config, cmake gettext glib atk libpng jpeg tiff freetype fontconfig pixman cairo pango gtk+ fltk gsl libdc1394 opencv player stage

I also enjoy having some of the standard stuff, like wget and imagemagick and mplayer

tom5760 · 2009-02-08 00:43:31

gorn wrote:

It also requires some design decisions, do we install our own python?

I feel that we should provide the newest UNIX software available. i.e. our own Python, bash, etc. unless there is some technical reason not to.

gorn wrote:

Do we try to keep the PKGBUILD's as close to Archlinux's as possible, or are we just interested in pacman?

In order to keep things as simple as possible, and so we do not duplicate efforts, I'd say copy the PKGBUILDs as close as possible, only changing things when needed to suit OSX.

gorn wrote:

If we install with something like /opt/arch/usr so the PKGBUILD's don't need modifying for prefix, we could try to become mostly compatible with ABS and AUR packages, which would help out.

Agreed.

gorn wrote:

(Though PKGBUILD's often use GNU install, which supports more options than Mac install, so we'd need to install coreutils and put arch ahead in the PATH. Maybe just for PKGBUILDs though and not for the user.

Yeah... I ran into the GNU install issue... Like I said above, unless there is a technical reason not to install GNU coreutils, I'd say install it for the user as well.

gorn wrote:

What unix software is everyone here interested in?

Probably for now, we could just package things we ourselves use. If we gain more interest, we could worry about other things.

gorn wrote:

I also enjoy having some of the standard stuff, like wget and imagemagick and mplayer

Man, I can't tell you how many times I type "wget" in Mac... (I know I could have installed it...)

I think I'll set up a Google Code project just so we can start to get organized. I'll edit this post once I've done so.

EDIT:

And here it is! http://arch-osx.googlecode.com/. Let me know your account names (gorn, lloeki), and I'll add you as project members.

EDIT2: Great find for fakeroot gorn! Works great. Maybe you should email that upstream?

Last edited by tom5760 (2009-02-08 01:17:24)

gorn · 2009-02-08 02:18:22

tom5760 wrote:

gorn wrote:
It also requires some design decisions, do we install our own python?
I feel that we should provide the newest UNIX software available. i.e. our own Python, bash, etc. unless there is some technical reason not to.

I guess my concern with our own Python is that if you don't want the newest python, but some package requires python, you'll pull it even though Mac includes a perfectly good python install by itself. One thing I realized is that a package can provide without conflicting, so we can have a base macosx-10.5 which provides everything that macosx comes with (python=2.5.1) but a user can still pacman -S python or a package can require python>=2.6.0 or whatever.

I think I'll set up a Google Code project just so we can start to get organized. I'll edit this post once I've done so.
And here it is! http://arch-osx.googlecode.com/. Let me know your account names (gorn, lloeki), and I'll add you as project members.

I'll PM you my information.

EDIT2: Great find for fakeroot gorn! Works great. Maybe you should email that upstream?

Yeah I plan to email upstream but haven't yet.

Last edited by gorn (2009-02-08 02:20:32)

tom5760 · 2009-02-08 04:26:38

Just to let you guys know, I have just uploaded a Mac installer for pacman and related libraries (libarchive, etc, etc).

You can find the installer at: http://code.google.com/p/arch-osx/downloads/list

EDIT: Changes download link.

Last edited by tom5760 (2009-02-08 21:34:39)

Arch Linux

#1 2008-08-23 15:38:33

pacman on OSX (again!)

#2 2008-08-23 18:43:54

Re: pacman on OSX (again!)

#3 2008-08-23 22:14:16

Re: pacman on OSX (again!)

#4 2008-08-23 22:51:17

Re: pacman on OSX (again!)

#5 2008-10-30 08:17:02

Re: pacman on OSX (again!)

#6 2008-10-30 08:48:57

Re: pacman on OSX (again!)

#7 2008-10-30 17:46:51

Re: pacman on OSX (again!)

#8 2008-10-30 18:19:25

Re: pacman on OSX (again!)

#9 2008-10-30 18:28:28

Re: pacman on OSX (again!)

#10 2008-10-30 20:50:35

Re: pacman on OSX (again!)

#11 2008-10-31 01:31:26

Re: pacman on OSX (again!)

#12 2008-10-31 11:04:15

Re: pacman on OSX (again!)

#13 2008-11-08 20:21:42

Re: pacman on OSX (again!)

#14 2008-11-09 14:29:52

Re: pacman on OSX (again!)

#15 2008-11-09 14:50:31

Re: pacman on OSX (again!)

#16 2008-11-09 15:04:38

Re: pacman on OSX (again!)

#17 2008-11-17 22:39:23

Re: pacman on OSX (again!)

#18 2009-02-07 02:06:26

Re: pacman on OSX (again!)

#19 2009-02-07 03:53:53

Re: pacman on OSX (again!)

#20 2009-02-07 06:24:10

Re: pacman on OSX (again!)

#21 2009-02-07 11:09:22

Re: pacman on OSX (again!)

#22 2009-02-07 19:20:48

Re: pacman on OSX (again!)

#23 2009-02-08 00:43:31

Re: pacman on OSX (again!)

#24 2009-02-08 02:18:22

Re: pacman on OSX (again!)

#25 2009-02-08 04:26:38

Re: pacman on OSX (again!)

Board footer