That time has passed, and now I will try to outline the relative advantages and disadvantages of Ports and Portage. Although, I have to admit, I'm currently typing this in vim on my Gentoo system.
First, a quick overview of Ports is in order. Think of it as Portage with different commands, and a different syntax for ebuilds. Instead of being written in BASH like ebuilds, FreeBSD ports are written in (BSD, not GNU) Makefile syntax. Here is, for example, the ports makefile for /usr/ports/archivers/zip (this is BSD-licensed code):
Code: Select all
# New ports collection makefile for: zip
# ftp://ftp.info-zip.org/pub/infozip/Info-ZIP.html
# Date created: 22 Dec 1994
# Whom: ache
#
# $FreeBSD: ports/archivers/zip/Makefile,v 1.27 2003/03/08 22:55:34 kris Exp $
#
PORTNAME= zip
PORTVERSION= 2.3
PORTREVISION= 1
CATEGORIES= archivers
MASTER_SITES= ftp://ftp.uu.net/pub/archiving/zip/src/ \
${MASTER_SITE_TEX_CTAN:S,%SUBDIR%,tools/zip/info-zip/src/,}
ZCRYPT_SRC= zcrypt29-exportable.zip
DISTFILES= zip23${EXTRACT_SUFX} ${ZCRYPT_SRC}
MAINTAINER= ache@FreeBSD.org
COMMENT= Create/update ZIP files compatible with pkzip
EXTRACT_DEPENDS=unzip:${PORTSDIR}/archivers/unzip
WRKSRC= ${WRKDIR}/${PORTNAME}-${PORTVERSION}
EXTRACT_ONLY= zip23${EXTRACT_SUFX}
MAKEFILE= unix/Makefile
MAKE_FLAGS= LOCAL_ZIP="-DUSE_CRYPT" -f
ALL_TARGET= generic
MAN1= zip.1
post-extract:
unzip -q -aa -o ${_DISTDIR}${ZCRYPT_SRC} -d ${WRKSRC} -x WHERE
do-install:
.for file in zip zipcloak zipnote zipsplit
${INSTALL_PROGRAM} ${WRKSRC}/${file} ${PREFIX}/bin
.endfor
${INSTALL_MAN} ${WRKSRC}/man/zip.1 ${PREFIX}/man/man1
.include <bsd.port.mk>
Code: Select all
# Copyright 1999-2003 Gentoo Technologies, Inc.
# Distributed under the terms of the GNU General Public License v2
# $Header: /home/httpd/cvsroot/gentoo-x86/app-arch/zip/zip-2.3-r2.ebuild,v 1.5 2003/09/05 22:49:03 msterret Exp $
IUSE="crypt"
DESCRIPTION="Info ZIP (encryption support)"
SRC_URI="http://www.ibiblio.org/pub/Linux/distributions/gentoo/distfiles/${PN}23.tar.gz
crypt? ( ftp://ftp.icce.rug.nl/infozip/src/zcrypt29.zip )"
HOMEPAGE="ftp://ftp.freesoftware.com/pub/infozip/Zip.html"
SLOT="0"
KEYWORDS="~x86 ~ppc ~sparc ~alpha ~amd64"
LICENSE="Info-ZIP"
DEPEND="crypt? ( app-arch/unzip )"
src_unpack() {
unpack ${A}
if [ "`use crypt`" ]; then
mv -f crypt.h ${S}
mv -f crypt.c ${S}
fi
cd ${S}/unix
cp Makefile Makefile.orig
sed -e "s:-O2:${CFLAGS}:" Makefile.orig > Makefile
}
src_compile() {
emake -f unix/Makefile generic_gcc || die
}
src_install() {
dobin zip zipcloak zipnote zipsplit
doman man/zip.1
dodoc BUGS CHANGES LICENSE MANUAL README TODO WHATSNEW WHERE
}
Now, let's move on to the relative advantages of each system.
* In sheer number of Ports/Ebuilds, FreeBSD wins. FreeBSD passed 9,000 ports a month ago, and Gentoo was somewhere around 4,500 the last time I checked. However, Gentoo has many ebuilds that aren't in Ports, and FreeBSD has many ports that aren't in Portage. FreeBSD and Gentoo are both kept up to date similarly. However, FreeBSD had both KDE 3.1.3 and GNOME 2.4 in its ports tree before Gentoo.
* In ease of installing packages, Gentoo wins here. While the commands are very similar and what happens when you type them is almost identical, the deciding factor is the Gentoo --pretend option. It is vastly superior to the FreeBSD counterpart.
* In ease of removing packages, FreeBSD has a huge edge on Gentoo. This is because Portage completely ignores dependencies when you emerge --unmerge something. I could emerge --unmerge kdelibs and Gentoo will orphan the other KDE packages I just spend 8 hours compiling without a second thought. FreeBSD, on the other hand, has something called reverse dependencies. If I 'pkg_deinstall -r gtk-2.2.4', FreeBSD, will remove all packages that depend on GTK2 (GNOME2, gvim, galeon, etc.). This makes tasks that are incredibly difficult on Gentoo, such as removing GNOME, incredibly easy on FreeBSD. Reverse dependencies are, of course, my most-wanted new feature in Portage.
* When we consider updating the ports/portage tree, it is essentially a comparison of rsync and cvsup. The primary method of updating the ports tree in FreeBSD is cvsup, and Gentoo uses rsync. Comparing them would take another article, but the short story is that cvsup is superior to rsync. Gentoo makes it easier to actually give the command to upgrade the tree, by building it into emerge (i.e. 'emerge rsync'). With FreeBSD, I have to call it externally (i.e. 'cvsup -g -L 2 /root/ports-sup').
CVSup vs. Rsync was discussed in the December 23, 2002 GWN:
* Once you've updated the ports/portage tree, you have to update the actual packages on your system. I would say this is a draw, as I have never had problems using 'emerge -Dup world' or 'portupgrade -Rva', respectively, on either system. However, I think Gentoo deserves a win here because it's emerge -p flag is more useful (and more colorfulThere has been some discussion in the Gentoo developer community about migrating away from Portage's dependency on rsync and instead utilizing CVSup. Currently used in FreeBSD's ports system, CVSup offers a few distinct advantages, as well as challenges, over rsync:
Local changes will be preserved if you want them to, just like anoncvs. Anyone who's ever had their package.mask file overwritten by an emerge rsync will appreciate this feature.
CVSup is faster and more efficient than rsync. This means that CVSup can improve the efficiency of our Portage mirroring system.
CVSup's threaded design allows for file transfer begin almost immediately, unlike rsync which must build a complete file list first. Surprisingly, CVSup uses the rsync algorithm (which is very efficient) internally to synchronize individual files, but uses a better approach than rsync when coordinating the updates of large numbers of files.
CVSup is written in Modula 3, which means that transitioning to CVSup will require some non-trivial steps to ensure that we have proper Modula 3 support on all architectures.
CVSup also has the added psychological benefit of making FreeBSD users feel more at home.
) than FreeBSD's portupgrade -n flag.* In support of Java packages, Gentoo easily beats FreeBSD because of java-config. This allows much easier, on-the-fly, switching of JVMs than anything currently on FreeBSD. The current FreeBSD java-config is unnacceptable. (I read somewhere, when looking into this, that the FreeBSD Java people were considering writing a java-config similar to Gentoo's.)
* Finally, when it comes to installing packages (i.e. precompiled ports or ebuilds), FreeBSD wins. For every release (and periodically in the interim), FreeBSD builds packages for just about every port in the tree. These packages can be install using 'pkg_add <package-file>' or 'pkg_add -r <package-name>'. The latter automatically downloads the package from a FreeBSD ftp mirror.
Overall, I don't think I can decide. Portage and Ports are both great systems; I would surely use one if the other did not exist. When (hopefully, not if) Portage gets reverse dependency handling (qpkg --query-deps and emerge depclean do not count), Portage would win decisively over Ports.
). I don't expect another 5000 packages in the same timeframe, but it will be interesting to see how the number of packages increases.
