To view parent comment, click here.
To read all comments associated with this story, please click here.
I spent two months with gentoo and came back screaming to ports, which gives me the same lean system with 1/10 of the configuration headache. And you can't have "more" recompiling - when you upgrade, you upgrade the packages you have installed.
FreeBSD ports miss information about versions (package abc requires def >=2.5). So, either you recompile all dependencies, even if you didn't intend to, and be on the safe side or try your luck and skip it. Also, I think there isn't a "stable" branch for ports, only "current" exists - that would be equivalent to running ~arch in Gentoo.
As for .pbi, it's intention is probably to install a few desktop apps e.g. firefox, but the rest of the system e.g. Gnome is still using tradional packages? (or I am wrong). That doesn't look good to me.
Re: CaptainFlint. portupgrade helps, but can't solve the above problems. As I said I haven't used binaries much though.
Edited 2006-02-15 13:52
For me it comes down to liking source compiled packages better. With faster machines now a days it is not that cumbersome. I did compile gnome 2.8 on a 450 mhz p3 with 128 megs of ram last year... took 2 days in total for everything. Did it again this year on a dual amd64s with 5 gigs of ram and it was < 2 hours.
FreeBSD ports miss information about versions (package abc requires def >=2.5). So, either you recompile all dependencies,..
No, not really - there are some occasions when you have to update related ports, but these are the exceptions, always notified in /usr/ports/UPDATING. So, for instance, there is an update to mysql. You compiled amarok with mysql support - which means, amarok now depends on mysql. When you portupgrade -a - which updates mysql to the newest version - you don't have to recompile amarok. Also, if you take a look at the Makefiles, most ports depend on the presence of specific libraries, not package version. Everything is handled automatically by portugprade/install tools - you don't have to skip anything, or have additional recompiles: most of the times (there are exceptions as I noted) when you update, you only update those packs that have newer version available in the ports tree. I might have misunderstood your post however, so please clarify if I missed your point.
Ports is a single version - supporting at least 4 branches of FreeBSD (4.x, 5.x, 6.x, 7-CURRENT) - I think that this is not a problem, in fact, it is a small miracle I believe
Ports are also very stable compared to ebuilds (except stable branch, which is slightly more outdated than ports). Yes, there are always broken ports (but currently, www.freshports.org doesn't differenciate between broken on $arch or $version - but they are working on it, so half of the ports marked as broken will probably work for you, because they might be broken on Fbsd 4.x, or on the Alpha, or any combinations).





Member since:
2005-09-10
I am a Linux person as well, and have used FreeBSD as my everyday desktop for 2 months in the past. It was great from a Slackware/Gentoo perspective, but ports were weak for upgrading the system. Too much recompiling (even more than Gentoo).
I wander why you say that - I spent two months with gentoo and came back screaming to ports, which gives me the same lean system with 1/10 of the configuration headache. And you can't have "more" recompiling - when you upgrade, you upgrade the packages you have installed. If you have more packages installed, there'll be more recompiling during an upgrade.
Now: my dream FreeBSD desktop would use apt-get-ish binary package management (handling versions and such) and still keep ports v2 around, somehow.
Well, pkg_add -r pkgname is roughtly equivalent to apt-get install pkgname. In fact, the FreeBSD ports system (and this feature alone makes it better than any pkg management I tried) makes it ridiculously easy to create binary packages, even from software you installed from ports! a pkg_create -R -b ooo-build* will build an ooo-build binary with all its dependencies in your current directory. This binary will be similar to a .deb - it knows exactly what packages are needed to be installed as dependencies, the pkg_* tools are able to fetch them automatically, etc. This makes deployment of customized, precompiled, optimized (for instance, for i686) binary packages very easy. You can build on one machine, and put the binaries on an ftp, and install them via pkg_add on the rest. Oh, and creating binary packages during installation is as easy as adding a single letter to portupgrade/portinstall: portupgrade -ap. -p will put a binary package in /usr/ports/packages (in fact, it will automatically create the same directory layout you would find on the official ftp repositories for binary packages) if it exists, or in the port directory if it doesn't.
.pbi probably can't scale much
What do you mean? What is "scaling" in the context of package management?