pacman on OSX (again!)

lloeki · 2009-02-08 13:06:24

awesome! glad to see things are gaining momentum.

I globally agree with all of the above. details follow (where I'll be thinking aloud):

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.

yes. it is essential that we keep on with the Arch & KISS philosophy all the way, vanilla as much as possible.

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

excellent idea. but won't 'pacman -S python' want to remove the original provider? maybe we should rather make a macosx-10.5 which pulls dummy macosx-python=2.5.1 packages, thus -S will remove that dummy and not macosx.

What's more, what osx version will we target? I guess most of us have 10.5(.6), should we target 10.4, and what will happen once 10.6 is out? also, I think we should also take into account ppc (10.4/.5) and x64 (10.5/.6) archs in the design. all of that shouldn't be too hard, we just have to think of it ahead .

I also think we should keep arch osx as encapsulated as possible. in we have to install some file out of /opt/arch, then strongly tell so upon install. my target was to have none of arch on the regular file system.

Personnally I was mostly interested in command line stuff. mencoder and texlive come to mind. I think we should also steer away from anything X11 related, and try to focus as much as possible on 'true' mac apps (in GUI department). my ultimate goal was to have some of the opensource mac-exclusive cocoa apps buildable and installable with pacman. I envision this project differently as for macports/fink, whose aim is to port as much apps as possible to the osx world, and I feel this results in badly integrated, out-of-place apps. this is arch-osx, not linux-apps-on-osx. I feel that if we don't go this way, we'll end up as just another fink/macports, just with another package manager. Although they are great and worthy projects, no offense to them, this is exactly why we don't like both of them.

In the end, as a developper, mono and cocoa# stuff is of big interest to me, allowing me to develop portable backend and specific, os-integrated frontend. Mind you, this is also true for python stuff (but work wants me to dev in C#).

I'd like this to feel simple, elegant, integrated and unintrusive with the mac experience. To me this is what the name Arch OS X represents.

lloeki · 2009-02-08 13:07:32

tom5760 wrote:

Just to let you guys know, I have just uploaded a Mac installer for pacman and related libraries (libarchive, etc, etc).
You can find it at: http://arch-osx.googlecode.com/files/arch-osx.pkg

this is simply great work, and a first, important, milestone. yay.

tom5760 · 2009-02-08 17:14:43

llokei wrote:

What's more, what osx version will we target? I guess most of us have 10.5(.6), should we target 10.4, and what will happen once 10.6 is out? also, I think we should also take into account ppc (10.4/.5) and x64 (10.5/.6) archs in the design. all of that shouldn't be too hard, we just have to think of it ahead .

I feel that we should just officially support the systems we own. If someone comes along and has a PPC or a 10.4 system, I'd gladly accept whatever changes they need to support their systems. But, for us, to support them, with no way of testing it, I feel would take too much time. We'll see...

llokei wrote:

I also think we should keep arch osx as encapsulated as possible. in we have to install some file out of /opt/arch, then strongly tell so upon install. my target was to have none of arch on the regular file system.

Thats the idea. Unless there is some compelling reason not to, I don't see why we can't install everything in /opt/arch.

llokei wrote:

Personnally I was mostly interested in command line stuff. mencoder and texlive come to mind. I think we should also steer away from anything X11 related, and try to focus as much as possible on 'true' mac apps (in GUI department). my ultimate goal was to have some of the opensource mac-exclusive cocoa apps buildable and installable with pacman. I envision this project differently as for macports/fink, whose aim is to port as much apps as possible to the osx world, and I feel this results in badly integrated, out-of-place apps. this is arch-osx, not linux-apps-on-osx. I feel that if we don't go this way, we'll end up as just another fink/macports, just with another package manager. Although they are great and worthy projects, no offense to them, this is exactly why we don't like both of them.

Well, the main reason I don't like fink or macports, is that it feels really difficult to create your own packages, or to edit packages to install newer versions. PKGBUILDs are so much simpler in that regard.

As for X11 packages (or any packages), I feel, if someone uses it, and is willing to maintain a package for it, then why not? I like to use some X11 apps on Mac (GIMP, etc.) and would like packages for them.

But I also have no problems with packaging Mac-exclusive stuff. I always felt Mac needed a good system-wide package manager.

llokei wrote:

I'd like this to feel simple, elegant, integrated and unintrusive with the mac experience. To me this is what the name Arch OS X represents.

Agreed. If you are interested, PM me you Google account name (if you have one), and I can give you SVN access so you can upload your own PKGBUILDs.

gorn · 2009-02-08 17:40:15

tom5760 wrote:

I feel that we should just officially support the systems we own. If someone comes along and has a PPC or a 10.4 system, I'd gladly accept whatever changes they need to support their systems. But, for us, to support them, with no way of testing it, I feel would take too much time. We'll see...

I agree. It'd be nice to support 10.4, 10.5, 10.6 and macx86 as well as macppc. But without the machines it will be hard to do.

llokei wrote:
I also think we should keep arch osx as encapsulated as possible. in we have to install some file out of /opt/arch, then strongly tell so upon install. my target was to have none of arch on the regular file system.
Thats the idea. Unless there is some compelling reason not to, I don't see why we can't install everything in /opt/arch.

I agree. I think we should patch makepkg so if anything falls outside of /opt/arch it gives us a big warning. Some packages are kind of tricky. I've run tar tzvf on the output sometimes just to confirm it's packaged right before installing it. I've just rm -rf'ed /opt/local or /sw countless times. I'd be annoyed if that didn't complete remove the package manager and it's packages.

As for X11 packages (or any packages), I feel, if someone uses it, and is willing to maintain a package for it, then why not? I like to use some X11 apps on Mac (GIMP, etc.) and would like packages for them.

I agree with llokie that we need to differentiate ourselves from MacPorts and fink, but I don't think we need to forget about X11. My primary use of MacPorts has been for dependencies including GTK+. The applications aren't beautiful, but they are important to me.

I always felt Mac needed a good system-wide package manager.

Maybe we should start packaging some Mac Only software to push this. Things like LaTeXit which have dependencies and are kind of a pain to install would work nicely with pacman.

lloeki · 2009-02-09 21:13:06

gorn wrote:

tom5760 wrote:
I feel that we should just officially support the systems we own. If someone comes along and has a PPC or a 10.4 system, I'd gladly accept whatever changes they need to support their systems. But, for us, to support them, with no way of testing it, I feel would take too much time. We'll see...
I agree. It'd be nice to support 10.4, 10.5, 10.6 and macx86 as well as macppc. But without the machines it will be hard to do.

of course we can't do it. all I'm saying is we should leave the possibility open in the design choices we're going to make. e.g if we take the macosx pseudopackage dependency path, how will we make it support multiple versions? remember pacman repos only support one version of each. therefore we'll have to have one repo for each osx version, like core/extra vs testing. you see, we have to think of things like that, to allow others to do the work we can't.

gorn wrote:

llokei wrote:
I also think we should keep arch osx as encapsulated as possible. in we have to install some file out of /opt/arch, then strongly tell so upon install. my target was to have none of arch on the regular file system.
Thats the idea. Unless there is some compelling reason not to, I don't see why we can't install everything in /opt/arch.
I agree. I think we should patch makepkg so if anything falls outside of /opt/arch it gives us a big warning. Some packages are kind of tricky. I've run tar tzvf on the output sometimes just to confirm it's packaged right before installing it. I've just rm -rf'ed /opt/local or /sw countless times. I'd be annoyed if that didn't complete remove the package manager and it's packages.

if you compile pacman with the --with-root config there's no way it gets out, since everything in the pkg gets anchored at the --with-root. out-of-root files can then only be installed at .install script time, which is, to me, the place the warning could go: there are already packages warning of stuff here, and it's logged in the pacman log. I suppose we could merely put some symlinks out there ppointing back to things in /opt/arch, which should work most of the time and get stale, be harmless and easily findable if you just remove /opt/arch. yet I do not know how/if it will work with stuff like kexts (thinking of macfuse or zfs for example)

gorn wrote:

As for X11 packages (or any packages), I feel, if someone uses it, and is willing to maintain a package for it, then why not? I like to use some X11 apps on Mac (GIMP, etc.) and would like packages for them.
I agree with llokie that we need to differentiate ourselves from MacPorts and fink, but I don't think we need to forget about X11. My primary use of MacPorts has been for dependencies including GTK+. The applications aren't beautiful, but they are important to me.

fine by me. I was mostly expliciting my personal objectives when I started working on this, I have no problem with people packagin X11 stuff. But you have to be aware there seems to exist some big constraints with X11 stuff, macports seems to have no other way but to put some stuff in /usr, and the single thought of it makes me shiver.

gorn wrote:

I always felt Mac needed a good system-wide package manager.
Maybe we should start packaging some Mac Only software to push this. Things like LaTeXit which have dependencies and are kind of a pain to install would work nicely with pacman.

Yes, I feel this is one of the main reasons opensource has a hard time gaining momentum on the platform (apart for the critical self-contained apps like Adium or Perian, and thanks to Sparkle they're easily updated). I hope this will help some

Well, the main reason I don't like fink or macports, is that it feels really difficult to create your own packages, or to edit packages to install newer versions. PKGBUILDs are so much simpler in that regard.

yes it is amazingly hard (needlessly complex?) to contribute to macports. almost as much as for gentoo . the same goes for upgrading/removing stuff. you end up with dozens of disabled, out of date packages and recursively removing orphaned stuff is a whole book in itself. I feel like I'm using rpm. pacman/arch is just so simple in comparison it just begs to be ported!

Last edited by lloeki (2009-02-09 21:49:29)

gorn · 2009-02-10 19:47:19

lloeki are you interested in joining the project? Shoot either myself or tom and email and we can add you to the google-code project.

lloeki wrote:

all I'm saying is we should leave the possibility open in the design choices we're going to make. e.g if we take the macosx pseudopackage dependency path, how will we make it support multiple versions? remember pacman repos only support one version of each. therefore we'll have to have one repo for each osx version, like core/extra vs testing. you see, we have to think of things like that, to allow others to do the work we can't.

Tom and I were talking about this. I think we're ditching the macosx pseudopackage or at least making it less important. I really just want it so that it's not required to pull python/perl/etc to run a script that just needs the basic interpreter.

llokei wrote:

if you compile pacman with the --with-root config there's no way it gets out, since everything in the pkg gets anchored at the --with-root. out-of-root files can then only be installed at .install script time, which is, to me, the place the warning could go: there are already packages warning of stuff here, and it's logged in the pacman log. I suppose we could merely put some symlinks out there ppointing back to things in /opt/arch, which should work most of the time and get stale, be harmless and easily findable if you just remove /opt/arch. yet I do not know how/if it will work with stuff like kexts (thinking of macfuse or zfs for example)

The problem with --with-root is that some packages hardcode paths, so they'll look for libraries in /usr rather than /opt/arch/usr/lib, that can be worked around, but configuration files can be hard coded too, and that's harder.
MacFuse is something to think about...

I was mostly expliciting my personal objectives when I started working on this, I have no problem with people packagin X11 stuff. But you have to be aware there seems to exist some big constraints with X11 stuff, macports seems to have no other way but to put some stuff in /usr, and the single thought of it makes me shiver.

I really want to avoid putting anything outside of /opt/arch. But like you said if we do, I think it should be with a big warning and only put a symlink out there.

yes it is amazingly hard (needlessly complex?) to contribute to macports. almost as much as for gentoo . the same goes for upgrading/removing stuff. you end up with dozens of disabled, out of date packages and recursively removing orphaned stuff is a whole book in itself. I feel like I'm using rpm. pacman/arch is just so simple in comparison it just begs to be ported!

When working on arch-osx I sometimes get the great idea to see how MacPorts does it, then I get very confused trying to read a Portfile. I've never written one simply because the format is so crazy. I've written ebuilds before but always found it tedious. I feel in love with Arch because it's just so damn easy to write a PKGBUILD that I'll actually do it.

lloeki · 2009-02-10 19:59:12

lloeki are you interested in joining the project?

mail sent

The problem with --with-root is that some packages hardcode paths, so they'll look for libraries in /usr rather than /opt/arch/usr/lib

I build my packages with --prefix=/usr and anything respecting export DYLD_LIBRARY_PATH=/opt/arch/usr/lib works. nowadays most packages should. this allows for most PKGBUILDs to be taken almost as is.

for those that fail a possible solution would be to use --prefix stuff wisely at the ./configure time.
the trick could be to build them informing them they will --prefix /opt/arch (thus hardcoding /opt/arch/some/thing instead of /some/thing), and copy the relevant files from src/ into pkg/some/thing (instead of pkg/opt/arch/some/thing) so the package built is installable with a --with-root pacman.

if they don't have configure, then we have to sed the hardcoded stuff.

if this doesn't work I can't see what else we could do unless chrooting or poking upstream.

Last edited by lloeki (2009-02-10 20:17:22)

detto · 2009-02-16 21:23:47

I want to express a big thank you to your work and enthusiasm for this project!
It's like a dream comes true, and that just right in time as I was searching today for sth to manage packages on OS X.

lloeki · 2009-03-13 16:03:49

It's already very useable. You can try it for yourself at google code, and follow general discussions at google groups. Links above, or search . For now we lack hosting space for the bin packages so you will have to build packages by hand, but even then I'm already far more productive than with macports/fink.

danielsdesk · 2009-03-26 22:38:49

This is a seriously ambitious and awesome idea. I will definitely be paying attention.

freakcode · 2009-03-26 23:26:54

Looks cool, I might try it once I go Mac, as the thing I like most in Arch is pacman/PKGBUILD.

Ranguvar · 2009-03-27 01:53:03

I'll definitely try this and report back when I fool around with OSX86 in VMware. I'd never go Mac for reals, but it's nice to see Linux innovations (and Arch ones) spreading

tom5760 · 2009-03-28 03:22:55

Hopefully, I'll have time in the next few days to put together a new installer with fresh versions of the base packages. There have been some changes since the last installer version.

We still need to find somewhere to host binary packages. If anyone has any ideas, let me know (or send a mail to the list, or post here). It would be nice to offer real binary packages.

LTSmash · 2009-03-31 03:21:05

It would be great to use this as a base for creating an Arch/Darwin port... that of course I would like to use ... just imagine, Arch Darwin for i686... nice.

tom5760 · 2009-03-31 04:21:47

Just to let you guys know, I just uploaded a new installer a little while ago. Grab it at http://code.google.com/p/arch-osx/downloads/list

danielsdesk · 2009-04-06 14:16:38

Dummy question but where are you guys getting the binaries to be used by pacman? I know that you guys are still looking for a binary hosting provider, so are you downloading the binaries from somewhere else separately and then pointing pacman to them?

tom5760 · 2009-04-06 19:12:21

Right now, you need to build the packages from source using makepkg. We have a SVN tree full of PKGBUILDs to build packages with. Once you build it you can just use "pacman -U" to install it.

danielsdesk · 2009-04-07 15:28:10

is the svn tree on the google code site?

tom5760 · 2009-04-07 16:38:43

Yep, right under the "Source" tab.

http://code.google.com/p/arch-osx/sourc … n/packages

Xilon · 2009-04-07 18:40:59

Wow, nice thread. I wish I found it earlier. I see there's a little repository spawning here, which is great to see. I have been trying to make some packages for OSX myself. My (PKGBUILD) repo can be found on github: http://github.com/sebnow/macosx-alpm-pkgs/. I also started a Google Group once upon a time, to discuss packaging strategies and such: http://groups.google.com.au/group/mac-o … positories. I guess I can forget about that one since this one seems to have more activity .

Would be nice to merge these repositories and work on some proper ones (UNIX and Mac applications). The tricky part is packaging the system-provided stuff, either they're dummy packages, actual packages, or packages of the standard (non Apple) versions. I highly suggest against the latter - I completely destroyed my system, but it was fun .

Edit: I've also been writing a wrapper around libalpm for Objective-C to make a Mac OS X libalpm front-end, but so far it's stalled. I think I'll be working more on the libalpm code first, to improve it enough to make the wrapper easier to develop. Either way I hope to make a GUI front-end sometime soon (in the next few years, heh).

Last edited by Xilon (2009-04-07 18:43:49)

Stythys · 2009-04-08 04:18:40

for the binary hosting provider you're looking for, how much actual space do you think would be needed?

Xilon · 2009-04-08 12:36:46

Stythys wrote:

for the binary hosting provider you're looking for, how much actual space do you think would be needed?

If Mac OS X packages were to be included in the repositories (this could be a separate repository, on a different host), I'd say a lot more space would be used than for Archlinux. However, Archlinux would probably have more UNIX packages than there are on Mac OS X.

tom5760 · 2009-04-12 19:10:43

Stythys wrote:

for the binary hosting provider you're looking for, how much actual space do you think would be needed?

Right now, there are not that many packages, so I'm not sure. If you have any space, I'm sure we could restrict ourselves to whatever space limitations are needed.

Also, I am still working on one other lead for hosting, but it will still take a little while longer to work it out.

Stythys · 2009-04-12 20:12:04

well I don't have a ton of space, but I'd definitely be willing to host what I can

gorn · 2009-04-12 20:14:03

Stythys wrote:

for the binary hosting provider you're looking for, how much actual space do you think would be needed?

My internal binary repository is 400MB, though it doesn't include all of the binaries, and might include multiple versions of some of the same packages. But there is a ballpark figure for what we are looking at right now. As tom said, if you can offer space we can limit ourselves to whatever is available.

Arch Linux

#26 2009-02-08 13:06:24

Re: pacman on OSX (again!)

#27 2009-02-08 13:07:32

Re: pacman on OSX (again!)

#28 2009-02-08 17:14:43

Re: pacman on OSX (again!)

#29 2009-02-08 17:40:15

Re: pacman on OSX (again!)

#30 2009-02-09 21:13:06

Re: pacman on OSX (again!)

#31 2009-02-10 19:47:19

Re: pacman on OSX (again!)

#32 2009-02-10 19:59:12

Re: pacman on OSX (again!)

#33 2009-02-16 21:23:47

Re: pacman on OSX (again!)

#34 2009-03-13 16:03:49

Re: pacman on OSX (again!)

#35 2009-03-26 22:38:49

Re: pacman on OSX (again!)

#36 2009-03-26 23:26:54

Re: pacman on OSX (again!)

#37 2009-03-27 01:53:03

Re: pacman on OSX (again!)

#38 2009-03-28 03:22:55

Re: pacman on OSX (again!)

#39 2009-03-31 03:21:05

Re: pacman on OSX (again!)

#40 2009-03-31 04:21:47

Re: pacman on OSX (again!)

#41 2009-04-06 14:16:38

Re: pacman on OSX (again!)

#42 2009-04-06 19:12:21

Re: pacman on OSX (again!)

#43 2009-04-07 15:28:10

Re: pacman on OSX (again!)

#44 2009-04-07 16:38:43

Re: pacman on OSX (again!)

#45 2009-04-07 18:40:59

Re: pacman on OSX (again!)

#46 2009-04-08 04:18:40

Re: pacman on OSX (again!)

#47 2009-04-08 12:36:46

Re: pacman on OSX (again!)

#48 2009-04-12 19:10:43

Re: pacman on OSX (again!)

#49 2009-04-12 20:12:04

Re: pacman on OSX (again!)

#50 2009-04-12 20:14:03

Re: pacman on OSX (again!)

Board footer