OSNews learned that the Gentoo project is porting their software distribution system, Portage, to Mac OS X. This makes Gentoo the third project developing such a system for the Unix-based OSX, after Fink and Darwin Ports. The Gentoo project also plans to create a GUI for OSX at some point, there is no ETA for it so far. Update: There might be some collaboration with Fink to also support their .debs. Update 2: The news are now on Gentoo’s front page.Additionally, we learned than the PPC team which brought us the Live CDs yesterday, are working on problems users have reported and a newer version are to be expected soon which fixes sound on the Gnome CD, automatic hardware detection and X startup etc.
Gentoo to Port Portage to Mac OS X
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
but jeez how many source based app distribution systems do we need.
… that I have ever seen that would make me consider purchasing Apple hardware. (And yes, I have seen and played with the OS X gui previously.)
Fink is here, and has been here. It’s mature and accomplishes exactly the same function. There’s already a GUI frontend for it, Fink Commander.
They are obviuosly not interested in it.
with portage going for OSX, how soon will we get pkgsrc and ports there too?
My experiences with fink are, that fink-packages are often outdated. There are too less contibutors for too much packages, so they can´t stay up-to-date. Also if a download-location changes, the package can´t be downloaded. So such a source distribution needs a lot of contibutors, who stay up-to-date and a lot of users, who tell the outdated packages. Due to the wider spreading of Gentoo, I can imagine it will be a better solution than fink.
Anton
>There are too less contibutors for too much packages, so they can´t stay up-to-date
Don’t expect better from Gentoo though. The Gentoo-PPC team is even smaller.
How many? Ask the Linux community how many text editors we need… the answer is ALL OF THEM.
Personally, I think this is grand! What better marrige then the best of desktop Linux and the best of desktop Unix?
Can’t wait to see how it turns out!
Fink is here, and has been here. It’s mature and accomplishes exactly the same function. There’s already a GUI frontend for it, Fink Commander.
This whining over multiple projects that accomplish the same thing has reached the point of ridiculousness. Do you bitch and moan when you go to a car lot and see two different sports cars? Do you say, “Why is there a mercedes? It can’t do anything the jaguar can’t?” How about in a liquor store? Do you whine and complain when you have a choice between beer, tequila, or some kind of mixed drink?
Just because Gentoo ports this to OSX doesn’t mean you can’t use Fink. If you like Fink then use it for God’s sake. Others may prefer portage. Complaining doesn’t make you right, just whiney.
Taking into consideration that these guys released ppc livecds, something that even YDL didn’t bother doing and that the GentooPPC guys’ only primary function is to put keywords in ebuilds one can conclude that your comment make no sense. You’re obviously don’t getting the point that the same ebuilds are used for all architectures/platforms which renders your claim that they can’t stay up to date useless.
I think Fink suffers from the same problems as Debian ironically. They actually do tend to offer a fair ammount of recent stuff, but not in the stable tree. So I normally go with unstable and build from source myself. Takes a bit more time but works just fine.
If they added that support too then we’d have an almost instant fallback to SCO’s tantrums!
I’m curious how similar the code bases actually are between OSX and Linux. Something like this would make cross-platform development much easier–you’d have lots of instant testers!
way to go!
I’ll skip the first part of your post because it’s nothing but pointless analogies…
Just because Gentoo ports this to OSX doesn’t mean you can’t use Fink.
No, but now they have thrice duplicated the functionality of a packaging system, a component which is integral to software distribution and is the most divisive aspect of Linux distributions. Lack of a standard packaging system is one of the biggest problems facing Linux today.
Not only is the effort of duplicating the packaging system itself wasted, but also the effort of maintaining packages to be used by the packaging system.
If you like Fink then use it for God’s sake.
As many have stated, Fink has issues with out-of-date packages due to the current lack of package maintainers. Instead of stepping up and voluneering to be package mantainers, the Gentoo people are instead duplicating an already completed and mature effort of building a packaging framework on top of OS X, after which time they will hopefully become maintainers for the Gentoo/OS X package repository. But as others have stated, there are fewer developers in Gentoo’s PPC branch than there are developers working on Fink… how can they hope to ever compete?
The Gentoo system will have identical functionality to Fink. Can anyone name a single advantage the Gentoo system will employ over Fink? All I see this being is an incompatible packaging framework with no technological advantages to justify its existance.
Instead of starting such a useless project, Gentoo developers should focus on Portage problems and give their users the possibility to do FULL and CLEAN software removal (ever tried emerge -C kde ?). This is my only problem with Portage.
<quote>The Gentoo system will have identical functionality to Fink. Can anyone name a single advantage the Gentoo system will employ over Fink? All I see this being is an incompatible packaging framework with no technological advantages to justify its existance.</quote>
The fact that one cannot use fink on linux is reason enough to justify gentoo-osx existance. I don’t see how the gentoo packaging system can be incompatible to the fink packaging system when both use the same source tarballs.
Another point you don’t seem to understand is the -fact- that gentoo-osx will simply reuse gentoo-x86/ppc/sparc/arm/hppa/… ebuilds while fink has to build its own stuff from scratch.
USE flags are a pretty damn big advantage over fink.
Aye, I think it’s one of the biggest problem with portage… I once emerged Gnome and its 32768 dependencies, and um, I was only able to unmerge Gnome itself, not even its libraries.
They should also consider to make a GUI. Yes, I know how to use the command line, but GUIs tend to be easier to use. It would be nice to select masked/unmasked packages like you want, etc. I’m sure they would gain much more popularity.
Instead of stepping up and voluneering to be package mantainers, the Gentoo people are instead duplicating an already completed and mature effort of building a packaging framework on top of OS X, after which time they will hopefully become maintainers for the Gentoo/OS X package repository.
I personally don’t WANT the gentoo people “stepping up” to work on Fink. I want the Gentoo people doing everything they can to advertise and improve Gentoo. If portage introduces OSX users to Gentoo then that is a good thing. I don’t see why you think they should jump over and work on Fink when all the work that has gone into portage has made it a very usable tool.
I fail to see why those working on the Gentoo project should abandon portage for Fink. A better question could be why Fink didn’t use portage in the first place? I am not saying they should have, but it makes as much sense as your questioning a portage port for OSX.
The fact that one cannot use fink on linux is reason enough to justify gentoo-osx existance.
How would having Fink on Linux help anything? Fink is already using a number of tools for Debian, but that’s inconsequential… Fink is designed to be a packaging system for OS X.
How does Gentoo’s use as a packaging system for Linux help make it a better packaging system for OS X? Code reuse? Fink is already doing that, but it’s using Debian tools.
I don’t see how the gentoo packaging system can be incompatible to the fink packaging system when both use the same source tarballs.
The largest and most obvious intercompatibility issues will be the discontiguous underlying packaging systems and discontiguous dependancy trees.
Another point you don’t seem to understand is the -fact- that gentoo-osx will simply reuse gentoo-x86/ppc/sparc/arm/hppa/… ebuilds while fink has to build its own stuff from scratch.
I’m not familiar enough with Gentoo to understand exactly what you’re saying here… I can’t seem to find exactly what an “ebuild” is and don’t understand why you’re listing off a number of ISAs, most of which aren’t PPC.
If by “fink has to build its own stuff from scratch” you mean the development of their own build system, this is a moot point. Fink’s build system is as mature as Gentoo’s, although it’s been tailored for OS X whereas Gentoo will have to be modified to accomidate OS X.
Furthermore, a number of the compatibility problems dealt with in Fink are ones that arise from OS X’s lack of support for a number of POSIX features, as well as problems that arise from the case insensitivity of HFS+. Gentoo will have no advantage in dealing with these issues, besides simply repackaging software already modified for OS X compatibility by the Fink team.
Eugenia, can you please tell us who told you about portage being ported to OSX?? I keep follow the Gentoo mailing lists and some people talked about it but no such decision.
anyway, I find it hard to belive. Gentoo devs already have way too much work to spend time porting stuff to OSX.
“I’m not familiar enough with Gentoo to understand exactly what you’re saying here… I can’t seem to find exactly what an “ebuild” is and don’t understand why you’re listing off a number of ISAs, most of which aren’t PPC.”
yeah, thats the point. because gentoo is am source based system, you have a certain plattform independency you cant acieve from a binary based concept like fink. so thats the point and the booster for the power of OSS: people on a Mac will benefit from stuff people on Sun or AIX workstations figured out. in a seamless transparent way. i think you didnt understant what gentoo is. and even cant imagine that something like gentoo exist. its a simple concept but a big revolution. like linux anyway.
I too want to know the source of this story it seems rediculous to me that the gentoo devs would waste their time on anything like this. Not that it wouldn’t be neat, but I don’t see the motivation. And again there is no evidence to support this that I can find.
Maybe the word packaging is making this discussion confusing. Gentoo does not package software like debian and fink build .debs. Gentoo makes/maintaines descriptions of how to install packages from source and allows users to tweak the installation using USE vars.
This whole database is called ‘portage’. What gentoo-osx did was to port the software that is able to handle these descriptions (the ‘portage’ interpreter) to osX. The reason I’ve named gentoo-HPPA/ARM/SPARC/PPC is because they all use the same (40.000) gentoo-created/maintained descriptions to allow you to install/configure/maintain a system on any of these platforms. So will gentoo-osx. Bringing gentoo to OS X is quite easy. One only needs to check the currently 40.000 descriptions to see if they work. Gentoo has a complete system in place to mark these descriptions (ebuilds) stable or unstable for a certain project (hppa/arm/sparc/osx/bsd/darwin/hurd/…). So claiming that gentoo on OS X will not be able to keep up with fink is a false statement.
Your statements about the lack of interoperability between fink and gentoo are also false. Just like fink is able to co-exist with OSX, so will gentoo be able to coexist with OSX and fink. you can have a gentoo X11 installed, an apple X11 and a fink X11. Depending on your path, the correct one will be chosen.
The Gentoo team might be smaller, but Portage is a huge advantage for them. The Gentoo team is a lot smaller than the RedHat or Debian teams, but you’d never know it if you look at how huge the Portage database is. In particular, adapting an ebuild to a slightly different situation (new version of software, different architecture) is trivial. Think about this: the initial port of Gentoo to the Alpha was done in 2 days by one person. Even with its tiny team, Gentoo supports 4 or 5 architectures. Beyond that, Portage makes it very easy for users to create their own ebuilds. I wouldn’t be surprised if forums.gentoo.org becomes a steady source of user-submitted OS X ebuilds.
Anonymous: yeah, thats the point. because gentoo is am source based system, you have a certain plattform independency you cant acieve from a binary based concept like fink.
You don’t appear to be familiar with Fink. Fink allows installation of binary packages or building packages from source. The fink tool itself is used to build packages from source, whereas binaries can be installed via dselect or apt-get.
Anonymous: so thats the point and the booster for the power of OSS: people on a Mac will benefit from stuff people on Sun or AIX workstations figured out. in a seamless transparent way.
And what specifically are you saying here, and how is the Gentoo package framework going to help accomplish that?
Anonymous: i think you didnt understant what gentoo is. and even cant imagine that something like gentoo exist. its a simple concept but a big revolution. like linux anyway.
That’s a rather arrogant statement about a system which was more or less copied from FreeBSD’s ports system…
mQuadra: This whole database is called ‘portage’. What gentoo-osx did was to port the software that is able to handle these descriptions (the ‘portage’ interpreter) to osX.
Unfortunately this will not help for a number of package, as a large amount of the “real” work involves modifying packages to build properly on OS X, due to its lack of a number of POSIX features which I mentioned previously.
mQuadra: Bringing gentoo to OS X is quite easy. One only needs to check the currently 40.000 descriptions to see if they work.
Yes, that doesn’t sound like a significant undertaking at all…
If Gentoo wants this to be successful they will need a considerable number of developers to handle altering the build environment to handle OS X.
As you claim, there’s 40,000 packages that need to be checked/modified for OS X support… better get cracking.
mQuadra: Your statements about the lack of interoperability between fink and gentoo are also false. Just like fink is able to co-exist with OSX, so will gentoo be able to coexist with OSX and fink. you can have a gentoo X11 installed, an apple X11 and a fink X11. Depending on your path, the correct one will be chosen.
And this is precisely the problem… I don’t want to have to install another copy of X11 just so it fits into a discontiguous packaging system. Fink and Apple have already worked together to make sure Apple’s X11 interopreates with Fink packages. Collaboration like this is why Fink is useful, and Gentoo developers will have to do a great deal of work to reach the degree of interoperability already present in Fink.
Think about this: the initial port of Gentoo to the Alpha was done in 2 days by one person.
Yes, but that’s changing ISAs which sit on top of an identical application layer. The game becomes a lot different when you’re attempting to modify your build environment to work on top of an entirely different application layer.
Even with its tiny team, Gentoo supports 4 or 5 architectures.
That’s 4 to 5 ISAs… but we’re talking a completely different operating system here. This is a major undertaking…
Beyond that, Portage makes it very easy for users to create their own ebuilds. I wouldn’t be surprised if forums.gentoo.org becomes a steady source of user-submitted OS X ebuilds.
I think the big question is how many people who would actually care about Gentoo’s build system for OS X actually have an OS X system…
Yaaay for gentoo
This might actualy make me get a mac 
Gentoo, a source-based metadistribution, is defined through it’s “meta-packaging” solution, called portage. Portage is conceptually similiar to the *BSD ports system. Portage consists of some +5000 ebuilds. Ebuilds are very tiny text files, which tell portage which source tarballs should be downloaded, where they should be downloaded, perfroms the ./configure/make/make install steps according to variables(USE flags) defined within the particular ebuilds and in the global /etc/make.conf file which allows one to fine tailor which optional modules/interfaces/parts of said package should be compiled in durig the make process. Additionally portage checks for dependencies, downloads additional dependencies, recursively, automatically and configure, compiles and installs them. Ebuilds are for the most part architecture agnostic- the same ebuild works on a half a dozen different cpu architectures.
Maintaining an ebuild is absolutely trivial in comparision to maintaining a binary backage. Newbies with no programming experience whatsoever can usually figure out how to write their own simple ebuild within weeks of learning to use gentoo. It is much, much easier to maintain a set of ebuilds than any kind of binary distribution. The flexibility, simplicity and power which portages ebuilds puts in the hands of ordinary users is incredible- when you consider how difficult it is to say, download the mplayer sourceball and manually configure it to use exactly these codecs and no others and then to have to recursively go through a mostly undo ration step involved in compiling each of them. With gentoo I simply define a USE flag- either on the command line as an evironment variable or in /etc/make.conf(USE=”mpeg oggvorbis divx dvd encode decode alsa gtk2 X arts sse mmx”) and then “emerge mplayer”- each use flag and the associated dependency requirements of each is automatically resolved(98% of the time without any further ado) downloaded ,configured,compiled and installed in the right order-so that each package profits from the enable resp. disabled features of the previous packages.
<quote>That’s 4 to 5 ISAs… but we’re talking a completely different operating system here. This is a major undertaking… </quote>
Besides ISAs gentoo has been ported to -bsd and -hurd, so what if they port to -osx, -darwin, -bsd, or even -cygwin. I certainly won’t mind another effort that promotes open source, but that is another discussion.
here is an xmms ebuild- as an example(a rather lengthy involved one that is):
cat /usr/portage/media-sound/xmms/xmms-1.2.7-r19.ebuild
# Copyright 1999-2003 Gentoo Technologies, Inc.
# Distributed under the terms of the GNU General Public License v2
# $Header: /home/cvsroot/gentoo-x86/media-sound/xmms/xmms-1.2.7-r19.ebuild,v 1.5 2003/03/19 08:10:31 nakano Exp $
IUSE=”xml nls esd gnome opengl mmx oggvorbis 3dnow mikmod directfb ipv6 cjk”
inherit libtool flag-o-matic eutils
filter-flags “-fforce-addr”
S=”${WORKDIR}/${P}”
DESCRIPTION=”X MultiMedia System”
SRC_URI=”http://www.xmms.org/files/1.2.x/${P}.tar.gz
mmx? ( http://members.jcom.home.ne.jp/jacobi/linux/etc/${P}-mmx.patch.gz )”
HOMEPAGE=”http://www.xmms.org/“
SLOT=”0″
LICENSE=”GPL-2″
KEYWORDS=”x86 ppc sparc alpha”
DEPEND=”app-arch/unzip
=x11-libs/gtk+-1.2*
mikmod? ( >=media-libs/libmikmod-3.1.6 )
esd? ( >=media-sound/esound-0.2.22 )
xml? ( >=dev-libs/libxml-1.8.15 )
gnome? ( <gnome-base/gnome-panel-1.5.0 )
opengl? ( virtual/opengl )
oggvorbis? ( >=media-libs/libvorbis-1.0_beta4 )”
RDEPEND=”${DEPEND}
directfb? ( dev-libs/DirectFB )
nls? ( dev-util/intltool )”
src_unpack() {
unpack ${P}.tar.gz
cd ${S}
# Patch to allow external programmes to have the “jump to” dialog box
epatch ${FILESDIR}/xmms-jump.patch
# Save playlist, etc on SIGTERM and SIGINT, bug #13604.
epatch ${FILESDIR}/xmms-sigterm.patch
# The following optimisations are ONLY for x86 platform
use x86 && (
# For mmx/3dnow enabled CPUs, this patch adds mmx/3dnow optimisations
#
# ( use mmx || use 3dnow ) &&
# cat ${DISTDIR}/${P}-mmx.patch.gz | gunzip -c | patch -p1 || die
#
# For you guys who favour this kind of USE flag checking … this
# is exactly why I do NOT like it, because the actual
# “cat ${DISTDIR}/${P}-mmx.patch.gz | gunzip -c | patch -p1 || die”
# was not in a subshell, it would ALWAYS fail to build if “mmx”
or
# “3dnow” was not in USE, because of the || die at the end. So
# PLEASE, PLEASE test things with all possible USE flags if you
use
# this style!!!! Then, if in a subshell, it do not detect if the
# command fails :/
#
# Azarah – 30 Jun 2002
#
if use mmx || use 3dnow
then
epatch ${DISTDIR}/${P}-mmx.patch.gz
use ipv6 && epatch ${FILESDIR}/xmms-ipv6-20020408-mmx.patch
else
use ipv6 && epatch ${FILESDIR}/xmms-ipv6-20020408-nommx.patch
fi
)
# Patch for mpg123 to convert Japanese character code of MP3 tag info
if use cjk; then
epatch ${FILESDIR}/${P}-mpg123j.patch
fi
[ ! -f ${S}/config.rpath ] && (
touch ${S}/config.rpath
chmod +x ${S}/config.rpath
)
# We run automake and autoconf here else we get a lot of warning/errors. # I have tested this with gcc-2.95.3 and gcc-3.1.
elibtoolize
echo “>>> Reconfiguring…”
for x in ${S} ${S}/libxmms
do
cd ${x}
aclocal
export WANT_AUTOCONF_2_5=1
automake –gnu –add-missing –include-deps Makefile || die
autoconf || die
done
}
src_compile() {
local myconf=””
use gnome
&& myconf=”${myconf} –with-gnome”
|| myconf=”${myconf} –without-gnome”
use 3dnow || use mmx
&& myconf=”${myconf} –enable-simd”
|| myconf=”${myconf} –disable-simd”
use esd
&& myconf=”${myconf} –enable-esd –enable-esdtest”
|| myconf=”${myconf} –disable-esd –disable-esdtest”
use mikmod
&& myconf=”${myconf} –enable-mikmod –enable-mikmodtest
–with-libmikmod”
|| myconf=”${myconf} –disable-mikmod –disable-mikmodtest
–without-libmikmod”
use opengl
&& myconf=”${myconf} –enable-opengl”
|| myconf=”${myconf} –disable-opengl”
use oggvorbis
&& myconf=”${myconf} –enable-vorbis –enable-oggtest
–enable-vorbistest –with-ogg”
|| myconf=”${myconf} –disable-vorbis –disable-oggtest
–disable-vorbistest –without-ogg”
use xml
|| myconf=”${myconf} –disable-cdindex”
use nls
|| myconf=”${myconf} –disable-nls”
use ipv6 && myconf=”${myconf} –enable-ipv6″
econf ${myconf} || die
### emake seems to break some compiles, please keep @ make
make || die
}
src_install() {
make prefix=${D}/usr
datadir=${D}/usr/share
incdir=${D}/usr/include
infodir=${D}/usr/share/info
localstatedir=${D}/var/lib
mandir=${D}/usr/share/man
sysconfdir=${D}/etc
sysdir=${D}/usr/share/applets/Multimedia
GNOME_SYSCONFDIR=${D}/etc install || die “FOO”
dodoc AUTHORS ChangeLog COPYING FAQ NEWS README TODO
dodir /usr/share/xmms/Skins
insinto /usr/share/pixmaps/
donewins gnomexmms/gnomexmms.xpm xmms.xpm
doins xmms/xmms_logo.xpm
insinto /usr/share/pixmaps/mini
doins xmms/xmms_mini.xpm
insinto /etc/X11/wmconfig
donewins xmms/xmms.wmconfig xmms
use gnome && (
insinto /usr/share/gnome/apps/Multimedia
doins xmms/xmms.desktop
dosed “s:xmms_mini.xpm:mini/xmms_mini.xpm:”
/usr/share/gnome/apps/Multimedia/xmms.desktop
) || (
rm ${D}/usr/share/man/man1/gnomexmms*
)
# causes segfaults for ppc users #10309 and after talking
# to xmms dev’s, they’ve punted this from the src tree anyways …
rm -rf ${D}/usr/lib/xmms/Input/libidcin.so
}
pkg_postrm() {
if [ -x ${ROOT}/usr/bin/xmms ] && [ ! -d ${ROOT}/usr/share/xmms/Skins ]
then
mkdir -p ${ROOT}/usr/share/xmms/Skins
fi
}
though still somewhat involved the maintenance of such requires very little time in comparision to binary packages…..Before you criticize something as superfallous, or worse yet as something which would introduce “packaging nightmare” problems as posed by linux redhat/suse/mandrake/debian etc- into the OS-X world, you should inform yourself about what it is that you are talking about(ie. in what sense is an “ebuild” a package ?) …Hopefully this sheds some light ont he subject matter at hand…..
All I can say is read my past comments…
But quickly, I’ll summarize:
Fink, while providing packages, is not simply a “binary distribution”, you can choose to ignore the existance of the binary packages and build everything from source through fink. This is the functionality provided by the “fink” tool itself. If you wish to use binary packages through Fink’s system, you use only the Debian tools, apt-get, dpkg, and dselect, and don’t need touch “fink” at all.
And once again, more confusion between discontiguous ISAs and discontiguous application layers…
The implecation here is similar to saying that one could take the FreeBSD ports system, which is, of course, tailored to FreeBSD, untar the ports tree on Linux, and expect that making it work would be trivial. Doing so would defeat the entire purpose of the ports tree, which is to provide an easy way to handle incogruities between a given package and the FreeBSD application layer.
Portage is designed around Linux. The application layer differences between Linux and OS X are quite exensive, and thus the amount of effort involved in porting a single package increases significantly.
Though as this is the third time I’ve had to reiterate myself, this is a concept that people simply cannot grasp…
for those wondering where the information is originating from, check out http://www.gentoo.org, they have added this piece to the news.
So is this going to work with Aqua or am I going to need X11? Then which X11? I have apple’s X11 already installed. Fink I know works with that X11, will Gentoo work with it as well? Or am I going to have install another X11? IF I have to have 2 X11’s one thats highly integrated with Aqua and one thats not can some tell me how this doesn’t count as bloat? A solution of lets have X amount of X Servers running on OSX is kind of funny comming from the linux camp. (i.e. the anti-bloat nazi’s)
I can understand the value of gentoo’s portage tree for OSX, having it an fink would be great in terms of getting programs – however having multiple X11 servers would rate high on dumb idea list. Having 2 window servers (Aqua and AppleX11) to begin with is a bit of a chore just to run linux programs; but a 3rd (2nd X11 Server) just to install them? Its a bit daft no?
>>There are too less contibutors for too much packages, so >>they can´t stay up-to-date
>Don’t expect better from Gentoo though. The Gentoo-PPC >team is even smaller.
Portage was designed with being easy to maintain in mind. I often can just rename an ebuild to the newest version, and bam – it downloads and install the newest version. This doesn’t work for more complicated ebuilds, but it does work often.
I guess they don’t know anything about others distributions, don’t they?
A ebuild is not very different from a debian/rules file… They do almost the same thing.
“emerge mplayer” is almost the same thing as “apt-get source mplayer; fakeroot debian/rules; dpkg -i mplayer-xxxx-xxx.deb”. They download the tarball, patch the folder, etc.
And with rpms, I hear you can do something like rpm-build, but I didn’t try it myself.
Saying that gentoo is a “revolution” is kind of, well, stupid. As someone else said, it was taken from FreeBSD. And it’s not that convienant. If you want to spare CPU cycles compiling, good for you, but I don’t mind.
And for people saying that they really learn with gentoo, I guess you learn more than with Lindows, but with debian or slackware you’ll learn as much.
You’re missing the point. The Gentoo team isn’t porting the software, just maintaining .ebuild’s (package descriptions) for already-ported software. While it may be more complicated to port from Linux to OS X than from Linux/x86 to Linux/Alpha, it is really not any more complicated to maintain build scripts for Linux vs OS X. In both cases, it just boils down to slight differences in commands you pass to the build scripts. Heck, because of the widespread use of Autoconf and Automake, the actual build instructions will be nothing more than configure && make && make install in many cases. As for the number of OS X users willing to contribute to the Portage database, I think you’d be surprised at effective a single user with knowledge of shell scripts can be. Just a couple of dozen regulars could keep the important packages up to date.
I guess you are missing the point that the fink project can do the same.
Hm. Gentoo bashing seems to have become popular lately. While Gentoo is definately based on the ports system, it takes ports quite a bit further, mixing in a strong user-customization aspect that ports just doesn’t have. Also, .ebuilds are an order of magnitude easier to make than debs or rpms. As for compiling, its not a very good arguement. Gentoo users do their compiling offline. They don’t sit there are watching text scroll by, with their machine locked up, waiting for a package to finish. The start it as a background process, and let it use whatever spare cycles it can get. Right now, I’m compiling kde-cvs. I’ll get back to it tomorrow morning and it’ll be done. No wasted cycles here! And you *do* learn more using Gentoo, if only because the Gentoo documentation is incredibly detailed and well written, and the forums are extremely informative.
PS> Look, I used Debian for a long while, and I have absolutely no problem with them. I don’t even think of the two as competing with each other — they’re aimed at different types of users. But I take offense to people who claim that Gentoo users “don’t know anything about other distributions.”
…almost the same thing… Heh. Yeah, almost.
I agree that the Portage system is not a revolution, but it’s certainly an evolution. It’s more convenient that ports or apt-get in many ways. You can mask the packages you want (or not) with USE flags. You can also choose the compilation flags you want. The package management is also great (except for the cleaning). You can also get some binary package if you want. I believe you can also get Debian & Redhat packages if you prefer them.
Didn’t Jordan evaluate portage and decide he’d build his own? My money would be on darwinports; if the community supported it.
Like portage its build from source, but it is designed to support OSX features such as software update etc. Consequently one would expect Apple to internally adopt it for all their iCocoa stuff, inc Safari.
Though the possibilities for enthusiasts are intriguing. Theoretically at least, one could have a shared drive for multiple OSes, an OSX box, an older Gentoo PPC box or an x86 Gentoo system.
The same integration is theoretically possible, should someone undertake such an effort, for fink/debian too. Of course if someone ported darwinports to *fav-distro-here*…
(Let’s not mention RPM!!)
So the future is bright, let the package wars begin!
Me, I’ll still with Java Webstart – if that’s not available ant and cvs.
I agree that, when compiling from source, USE flags are easier than changing the debianl/rules to add –enable-gtk or something.
But I don’t compile from source, I use binary packages
Of course you don’t get FULL customization with them, but there is usually multiple binary packages when there’s compile-time only options. And if I really want to make MY binary package, I can make it without difficulties!
Of couse, you can compile in the background, but when there’s a new package, you need to wait. And installation is just BORING.
I’m not bashing Gentoo here, it’s still a good distribution, and it’s open source and all, and you can make crazy (but potientaly useless) optimisations on your system, but don’t tell me it’s the new “shit” and everything else just sucks. That is what annoys me the most with gentoo users.
Portage more convienant than apt-get? how? There’s “required” and “recommended” packages btw.
Yeah, I agree with the compilation flags, but you can always build from source (see above) and there are not really usefull most of the time (esp. after -02).
More Linux crap, that is all OSX needs.
Gentoo was a great way for me to learn linux and from the looks of the live cd, it has come a long way. I think the entire computer world are buying apple laptops from the look of all these site. This is a fantastic addition to an already great os.
Umm, this isn’t a full gentoo sponsored thing. Just something we’ve been tossing around the mailing list and one guy implemented in his spare time. Read the mailinglist for more information, right now its a really informal thing.
wow, i read the release on the frontpage of gentoo.com….this is really moving pretty quickly, as a few days ago itd just been an idea being tossed around.
Fink, Darwin Ports, and Portage all have advantages and disadvantages. Part of the problem with fink is that packages have to be bundled up in compiled debs which requires much more testing and inputted time than making an ebuild which is quite simple and more flexible when it comes to new versions of software coming out (especially point releases). It isn’t a totally duplicated effort, I consider portage better than apt/fink, which is why I’ve switched one of my main servers from debian to gentoo. Its more flexible, more up to date (despite the much smaller number of maintainers) and there seems to be less breakage. I recall times where glibc was broken in debian unstable. Gentoo seems to be able to remain the the bleeding edge and so far I’ve encountered no breakage at all. I’d argue that we’re better off with portage, and that debian’s package system is flawed in a certain sense (though its a HELL of alot better than redhat), if one considers ease of package maintainance, and ability to use the latest & greatest without having to use something that may or may not break on a daily basis.
So disappointed at Gentoo, which turns out to be another toy project. I will give up waiting for their next release, improvement on errata and release engineering…
Stay with FreeBSD, which has a much more trustable team.
I’m one of the core Fink maintainers and I also maintain some packages (and have even recently done some development) on darwinports, so I hope I at least have a little bit to say about this.
A lot of the comments are saying “why?!?!” Really people, you should know the answer by now. “Why not?” It’s a fun hack, it’s neat, it’s satisfying when you accomplish it. Who needs another reason? If other people get something out of it, great.
As for “what this means”, it means another infrastructure for porting pacakages. Yes, they’re duplicating functionality… I made the same complaints when darwinports started out but darwinports has done some pretty innovative things and has great plans for the future, so I’ve since decided I no longer have the right to ask why, it’s not my place.
You’ll find that the “packaging”, ie, making the package description, is the easy part. “Porting” is the hard part, and there is very little overlap in that space. A number of fink and darwinports developers hang out in each other’s irc channels, and there’s a lot of code-sharing that goes on patch-wise between the two. I maintain two sets of identical KDE packages, one in each, the only difference being how it’s packaged up. I see no reason things won’t work out that way with Gentoo in the mix too.
People really need to stop whining about what does what and go with what they like. If we’re all doing our jobs, very little overlap happens. Each system has it’s own advantages. Fink is very stable and has the largest number of packages. Darwinports is more bleeding-edge, but also supports “pure darwin” and darwin/x86 where in many cases Fink does not. Portage just adds another bit to the mix. I expect the most likely reason to choose portage over Fink or dports is for bleeding-edge and maybe custom compilation flags, but it remains to be seen how well that works.
In general, darwin is still a 2nd-class OS as far as support for “out-of-the-box” building. The Gentoo folks will find they need a lot more patches to make things play nice on darwin than for Linux, so some of the “immediate update”ness of gentoo may not happen on darwin just because someone will have to actively fix patches on each release of a port.
All in all, chill out people. If one of these packaging systems isn’t “good enough”, it will die out on it’s own. Darwinism (excuse the pun) will win out in the end. Otherwise, use what you like; I assure you, you won’t be hurting my feelings.
OSX doesn’t need any of that linux crap. Once OSX has FreeBSD’s ports life will be great!
>Gentoo seems to be able to remain the the bleeding edge and so far I’ve encountered no breakage at all.
I have. Last’ years libpng gentoo upgrade was disastrous and forced many people to recompile both kde gnome and lots of other things.
Is Gentoo funded by IBM? With Apple rumoured to start using the IBM PPC 970 cpu’s, there may be a connection here somewhere..
As a Debian user for four years, and as a Gentoo user for the last six months, I think I can comment on both.
First, Gentoo is primarily source based. This enables it to be nearly maintainance free by the developers, and keep a large and very updated package tree. Gentoo does have some binary packages for large things, such as Moz, Oo, KDE, GNOME, but I doubt that many people actually use those. It’s more for people who want to get a Gentoo system up and running real quick. Having to compile everything is not really an disadvantage unless you have real old hardware. Even then, you get “nice” the compile using portage.
I’ve found portage much more reliable than apt-get. If one
package after apt-getting something messes up, usually you won’t be able to use apt unless you fix it somehow. Portage has no such problems.
I’ve found Gentoo to be much more of an up-to-date distro than Debian. This was one of my major qualms with Debian when I left it. The unstable branch was getting simply pretty old, even compared to commercial distros. I was getting tired of going out and finding unofficial apt-sources, and having apt stop when one of them went down temporily.
Lastly, I’ve found the Gentoo developers and community to be much more open than Debian’s. It takes a somewhat lengthy process to become a Debian developer, including have to meet a current Debian developer to determine your identity. With Gentoo, all it takes is submitted enough ebuilds to Gentoo’s bugzilla (which usually ends up having to only rename the ebuild file.. ) If you submit enough ebuilds, you’ll eventually get write access to Gentoo’s CVS tree. It all works based on merit in gentoo.
I loved Debian when I used it for the most part. But for me, Gentoo is better.