Ports or packages?

[ciol]

Hi, I have some questions for desktop users only:

* Do you use packages or ports?
* Why?
* If you mix packages and ports, can you explain why and what is your ratio? (How many ports do you use compared to packages?).
* Is it possible to have only packages for desktop usage? (while still having security fixes).

Thank you.

[graudeejs]

1) i use ports, i only use packages if port fails.
2) because i like it, also building ports are little optimized for my cpu (CPU_TYPE). ports are more up to date
3) see answer 1. atm i use 1 package: xvidcap
4) It is possible, but packages are mostly outdated comparing to ports, however you can use packages, and then update with ports as necessary.

you can mix all you want as long as it satisfies you.
The end result will be same. An environment that works.


Keep in mind that some ports like ooo, kde, gnome and others takes a long time to compile. ooo takes more than 10h (don't remember how much more exactly) on my P4 @3GHz with 2G ram

[Djn]

Ouch, yes - OpenOffice is an absolute mess to compile. KDE isn't exactly fast, either.
Then again, I have OOo and KDE4 from ports, so with a little bit of patience (and leaving the computer on overnight) it works out. ;)

Tip: Do a make config-recursive before you start anything big. It's annoying to come back next morning and find that it's been waiting at a config screen since five minutes after you turned the monitor off.

[graudeejs]

Tip: Do a make config-recursive before you start anything big. It's annoying to come back next morning and find that it's been waiting at a config screen since five minutes after you turned the monitor off.

or use portmaster to install ports

[Djn]

Or that, indeed.

[dave]

Tip: Do a make config-recursive before you start anything big. It's annoying to come back next morning and find that it's been waiting at a config screen since five minutes after you turned the monitor off.

Great tip!

[dave]

I usually use ports, but if I am trying to get something up and running in a jiffy, and I don't need bleeding edge versions, then I will prefer packages for sure. In that case, I will only build a port if there is no package available for that application. I think it would be pretty rare to build a box that has no ports. So either mixed or all ports is probably really common.

[marius]

I've used ports on one machine, packages on another one, and I've also tried mixing them.

Packages are not very up to date. This means that you don't have the latest version of the program, which in it self is not that important, but what is important is the security. Many of the programs I install using packages have already security holes in them. If the programs don't have any holes when I install them, they will sooner or later end up with one or two, and waiting for someone to update that package can take ages. I always have to solve this problem by replacing the package with a port, since they are updated quite fast.

If I don't update the server to the latest version all the time, pkg_add will start having problems finding some of the packages (this can probably be fixed by setting the PACKAGESITE variable). It also seems like many of the mirror serves out there are not really mirrors. They don't have the same packages as some of the other servers.

Ports are always up to date and are updated as soon as a security hole has been found. If I only use ports I rarely see any trouble with my applications or updates I do. If I start mixing, or use packages only I do believe I get more errors and problems than if I had stayed with ports only.

Compiling is the biggest problem, it takes time. Sometimes it can take half a day if you have a slow computer, whatever a slow computer is these days :) Another thing with ports is that you can add or remove support for certain things, while this is not possible with packages since they are precompiled.

People also talk about optimization when using ports, but I've never really noticed, nor tried to notice any difference.

Personally I try to only use packages if I'm in a hurry and just need to test something. I wish I could use packages only since I find it rather.... time consuming and a bit 80's to have to compile for hours before you can use a program.

[kamikaze]

I use ports, not because I require them, but because they are they are up to date (security) and I like to experiment with the build process (paralleling with make -j, clustered builds with distcc and caching with ccache).

[SirDice]

I use ports on a build server to create my own packages. That way I can enable/disable options I want or not. Then use those packages to build or rebuild my workstation and servers.

[hitest]

I'm running an old Plll IBM so I primarily use packages for larger installations like KDE. I'll use ports for smaller programs.

[fender0107401]

http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/ports-overview.html

Ports system is an important feature of FreeBSD, as a software management system it is an invention. Comparing with package, I prefer ports. Using ports, you can learn how to build a package from source code(makefile, fetch, unpack, md5, solve dependency, compile, install, clean...).

But if you want to build your system in a short time, the package is useful than ports.

[dave]

I use ports on a build server to create my own packages. That way I can enable/disable options I want or not. Then use those packages to build or rebuild my workstation and servers.

A How-To (http://forums.freebsd.org/forumdisplay.php?f=39) on this would be nice!

[Kitche]

A How-To (http://forums.freebsd.org/forumdisplay.php?f=39) on this would be nice!

there is already a how to it's just a basic system that just builds ports or are you talking about making a jail for building ports which needs some tweaking to do it cleanly

[Mel_Flynn]

there is already a how to it's just a basic system that just builds ports or are you talking about making a jail for building ports which needs some tweaking to do it cleanly

It's a lot less simple then that:

make config-recursive does not catch all cases
When a library is updated, all packages depending on it need to be repackaged.
There is no way for a client machine to identify which packages are to be upgraded without having a local ports tree


There isn't a how-to for this. You need to write software for the "upgrade my client" part and there is tinderbox that can be used as buildserver, though not ideal it's better then writing your own.

[mbs]

I use only ports, I never used packages for mainly two reasons :
- the ports are up to date
- the compilation allows some configuration for a lot of port. I don't know how to do it with packages.

[cajunman4life]

...the compilation allows some configuration for a lot of port. I don't know how to do it with packages.

Simple answer: You can't. Packages are built by default with a "sane" set of options. The theory behind building packages is compile to the lowest common denominator... or more accurately, to what most people would "need".

If you need a different set of options, then ports are for you, as you can select exactly what options you want at compile time.

That said, I use ports. When building a desktop for the first time, I'll install everything via packages, and then once everything is up and running, rebuild everything from the ports tree to grab the latest patches (security patches, version updates, etc).

When building a server, I typically have more time, and will build everything using ports, as this allows me to remove things I don't need and add the things I do.

[aragon]

I mostly use ports because it's often easier to just cd into the port dir and run make install than hunting down a package file. I also find that default build options are frequently not ideal for me - packages are only built with defaults. This can often mean extra dependencies that you might not need or want.

I pretty much always install perl and python from a package though.

[Mel_Flynn]

I mostly use ports because it's often easier to just cd into the port dir and run make install than hunting down a package file.

Bad argument

# pkg_add -r www/firefox
Fetching http://packages-7:8050/www/firefox.tbz... Done.
Fetching http://packages-7:8050/All/nspr-4.7.tbz... Done.
Fetching http://packages-7:8050/All/nss-3.11.9_2.tbz... Done.
Fetching http://packages-7:8050/All/libIDL-0.8.11.tbz... Done.
Fetching http://packages-7:8050/All/pango-1.20.5.tbz... Done.
Fetching http://packages-7:8050/All/desktop-file-utils-0.15_1.tbz... Done.
Fetching http://packages-7:8050/All/shared-mime-info-0.51.tbz... Done.
Fetching http://packages-7:8050/All/zip-3.0.tbz... Done.
Fetching http://packages-7:8050/All/atk-1.22.0_1.tbz... Done.
Fetching http://packages-7:8050/All/gtk-2.12.11_1.tbz... Done.
===> Building Chrome's registry...

[aragon]

Bad argument
Good to know! I guess that part of my argument then changes to "because I'm so used to using ports". :)

[hedwards]

I use ports, not because I require them, but because they are they are up to date (security) and I like to experiment with the build process (paralleling with make -j, clustered builds with distcc and caching with ccache).
Does the -j switch work, or is it still a dummy switch? I ask because I'd love to use it, but last i checked it was still not completely finished and wasn't technically enabled.

Also, I generally compile all of my ports and keep a set of packages that I compile myself in case I need or want to reinstall my OS. It saves a huge amount of time later on because I can just place all the files and options into their appropriate directories.

[Andrius]

tl;dr - no, -j switch doesn't work

Long version:
For many ports something like "make patch && make -jN build && make install clean" will work (you can hack makefile to make this automated).
But:
Many ports won't build with -j switch and the time you "save" using -jN will be wasted by doing "make clean install clean" because build not only fails in the middle of compilation but also it is impossible to continue compilation even without -j switch. Well this is a rare case, and in most cases you CAN continue with "make build" when "make -jN build" fails, but do you really want to watch if it will fail or not when installing something? I certainly do not.

[drakus]

I mostly use packages. I have run into too many issues trying to compile large applications. Also, on many occassions, I have wanted to install and use applications immediately. I no longer believe in the performance argument. I mostly use Firefox, Gnome, Wireshark, Qemu, etc. All these take a long time to compile.

When 99% of everyone else can get equal performance with compiled programs, I don't think FreeBSD gives any greater advantage.

I would liek to see FreeBSD give packages first class citizen status so that the newest packages are available - I don't care if it is 3% slower performing than if I had compield from ports.

[SirDice]

As has been noted, performance isn't usually the reason why people compile from ports. It's the options.
And yes, compiling from ports takes a lot of time. That why I do it every once in a while. Start with a clean jail and build everything I need from scratch. Meanwhile everything will be packaged and stored. Building everything in a clean jail makes sure all the dependencies are also correct.

As for upgrading, pkg_deinstall -a, reboot* and pkg_add everthing again.


* Don't forget to pkg_add sudo before you reboot if you work remote ;)

[kamikaze]

Does the -j switch work, or is it still a dummy switch? I ask because I'd love to use it, but last i checked it was still not completely finished and wasn't technically enabled.The -j switch does work. How well depends on the quality of the make files.

The first rule is only to apply it to the make build target, this can be done automatically if something like portupgrade or portmaster is used, because they run the usual targets fetch, patch, configure, build and install separately.

The rule of the thumb is that 95% of ports compile without problems when using make -j.

I use buildflags from sysutils/bsdadminscripts to deal with all these things. This is an excerpt of my buildflags.conf file:
# ---< configure ports >-------------------------------------------------------
/usr/ports/*{
# Clustering
SUBTHREADS= 3
USE_DISTCC
USE_CCACHE

# No distcc or threading.
*/archivers/p7zip {!SUBTHREADS}
*/audio/cdparanoia {!SUBTHREADS}
*/audio/libsndfile {!SUBTHREADS}
*/audio/nas {!SUBTHREADS}
*/converters/libiconv {!SUBTHREADS}
*/devel/autoconf261 {!SUBTHREADS}
*/devel/doxygen {!SUBTHREADS}
*/devel/gperf {!SUBTHREADS}
*/devel/libthai {!SUBTHREADS}
*/devel/nasm {!SUBTHREADS}
*/devel/ncurses {!SUBTHREADS}
*/devel/ORBit2 {!SUBTHREADS}
*/devel/pth {!SUBTHREADS}
*/dns/libidn {!SUBTHREADS}
*/editors/vim {!SUBTHREADS !USE_CCACHE}
*/games/ultimatestunts {!SUBTHREADS}
*/graphics/libafterimage{!SUBTHREADS}
*/graphics/libart_lgpl {!SUBTHREADS}
*/lang/ruby18 {!SUBTHREADS}
*/multimedia/ffmpeg {!USE_CCACHE !USE_DISTCC}
*/multimedia/mplayer {!SUBTHREADS}
*/multimedia/mencoder {!SUBTHREADS}
*/print/ghostscript* {!SUBTHREADS}
*/print/scribus {!USE_CCACHE}
*/print/xdvik {!USE_CCACHE}
*/security/libgpg-error {!SUBTHREADS}
*/security/nss {!SUBTHREADS}
*/science/hdf5 {!SUBTHREADS}
}Of course this is shortened to the stuff relevant to this discussion. This is the complete list of troubling ports on a machine with more than 750 packages.

buildflags adds the -j parameter to MAKE_ARGS, so that the ports system itself is not affected.

[schtipoun]

I use packages for the first time install. And then, I use ports bcs ports are more up to date !

[ciol]

Keep posting guys.
I read fervently your posts even if I don't answer.

[techie]

I use ports on my server and I use packages and ports mixed on desktop PCs. On my old 500 MHz laptop I use packages only.

[ajh]

I am a desktop user, and I love FreeBSD. I use packages almost exclusively. As someone mentioned earlier, I've tried compiling OpenOffice and it takes forever. Same goes for Firefox. Don't even think about Java.

As far as picking the compile options is concerned, when was the last time you picked compile options when you installed a third-party application on Windows or the Mac? Do you really compile all of your applications for Linux machines when a package is available?

I've found that it takes very little time for an updated Firefox or Thunderbird package to become available for FreeBSD.

As far as being up to date is concerned, many non-security updates are gratuitous eye candy; updating them often leads to shared-library hell, and I end up wasting hours because of dependencies. After using Firefox 3 on FreeBSD, I decided that I liked Firefox 2 more, and downgraded.

I want a stable machine I can work on. I work full time, and hope to continue doing so, assuming this economy will allow it. I much prefer spending time helping my teenage sons learn to do just a little bit more every day with OpenOffice.org Writer and GNU Cash. They know they don't need to throw away hundreds of dollars on software when good, high-quality free alternatives are available.

I'm using this economic crisis as an opportunity to help my sons with their finances. If I do it right, they won't make the stupid mistakes that put this economy in the toilet. They got an eye opener when they graphed how large and fast debt grows at 25% compounded interest. When we sat down and made budgets for their allowances, they couldn't believe how much money they got in a year, and how much more they could have done with it if only they'd had a budget sooner. Among the other things we can do with FreeBSD, let's not forget to run the numbers.

This is a tech crowd, but unfortunately most of the world is not. Innumeracy is rampant, along with the attendant consequences.

By using packages, I have time to help them explore various websites for news and information about this wild, whacky, and marvelous world in which we live.

Given the choice between spending an hour tweaking a port to install and finding out what's happening on this forum, I'll spend the time checking out this forum, thank you. These are historic and interesting times that we're living in, and there is a lot of work to be done. Let us not squander the power that FreeBSD and other technologies give us.

Time is precious, and life is much too short. Long live packages!

[Mel_Flynn]

As far as picking the compile options is concerned, when was the last time you picked compile options when you installed a third-party application on Windows or the Mac? Do you really compile all of your applications for Linux machines when a package is available?


I think in this thread compile options are used for 2 distinct things:

Optimizations, that make software arbitrarily run faster
Options to packages, removing or adding features


The latter, is the most used reason to use ports or compile your own packages.

[ajh]

I think in this thread compile options are used for 2 distinct things:

Optimizations, that make software arbitrarily run faster
Options to packages, removing or adding features


The latter, is the most used reason to use ports or compile your own packages.

I trust that you use ports for the latter reason, but I have the impression that many people do so indiscriminately, not in order to customize the application, even when an equivalent package that will lead to an identical installation exists. They seem to think that installing from a package is inferior. I think your reasons for installing from ports is legitimate when the need arises, but there were frequent mentions in this thread of ports being preferable because they are allegedly more up-to-date. But that ain't always so: not everything in ports is the latest version of a particular piece of software.

I don't care to be on the bleeding edge, even though it may be more up-to-date. Up-to-date does not necessarily mean better, unless security issues or critical bugs exist that cannot wait until a package -- or port -- is available. Then I will go to the source and compile the application myself, whether or not a FreeBSD port or package exists.

(When I go to http://www.freebsd.org/ports to search for the odd application, I always grab the package if one exists. It is my understanding that using pkg_add to install that package is identical to running make && make install from an up-to-date ports tree. If so, how can installing from the identical port used to create the corresponding package be preferable in the absence of customization? It seems like wasted time to me.)

I now run RELEASE, recompiling the kernel only in response to security advisories. As a user, my most frequently used applications are plain-vanilla Firefox, Thunderbird, and OpenOffice.org. My impression of these applications is that they are stable, mature, and nontrivial projects. I assume that the default package install options are time-tested to be the "best" for the overwhelming majority of users on a platform-by-platform basis.

My experience with installing nontrivial applications from ports is that doing so at the very least takes significantly more time than installing from packages, and often causes more problems than I want to be bothered with. About the worst experiences involved installing ports that stomp on shared libraries -- by changing their versions, deleting them, or some other alchemy -- causing a cascade of failures in applications that were working just fine before make install.

When installing with packages, even when dependencies need to be satisfied, I can generally fetch the dependency package, install it and be on my merry way.

Let's not forget why compiling third-party applications became so commonplace: *nix implementations differed in so many respects -- manufacturer, machine, compiler, word size, peripherals, etc. -- that it was impractical to ship binaries even when the user and manufacturer would have preferred to do so.

As far as configuration options are concerned, shouldn't a well designed application provide utilities, configuration files, etc.? Consider FreeBSD itself: we use /boot/loader.conf, /etc/sysctl.conf, /etc/rc.conf, and so on to configure the system. We also use sysctl to customize a running system.

As a desktop user I value stability and my time above all. Imagine what my attitude is about infrastructure servers!

[Djn]

You're skipping over the other reason compiling applications is still popular, though: Many things have optional support for a mess of features that depend on external libraries (a good case in point is mplayer). You don't want to force people to install every single one, so the package has a moderate set of things enabled. If you want e.g. esound support (which I used to forward things over the network not too long ago), you just have to build it yourself.

As for problems, well - I have a very current ports, in order to get things like KDE 4. The available packages will usually be out of sync by a few minor versions, and that's not completely unproblematic either.

[Mel_Flynn]

I trust that you use ports for the latter reason, but I have the impression that many people do so indiscriminately, not in order to customize the application, even when an equivalent package that will lead to an identical installation exists.

Yeah, I don't share your view that most FreeBSD users are to quote House M.D "idiots", but think about what they need and don't need. Online help forums are not a good representation of the average FreeBSD user.


Then I will go to the source and compile the application myself, whether or not a FreeBSD port or package exists.
That's the easiest way to screw up /usr/local and /var/db/pkg.

It is my understanding that using pkg_add to install that package is identical to running make && make install from an up-to-date ports tree.

Wrong.
It is identical to make -DUSE_PACKAGE_DEPENDS -DPACKAGE_BUILDING -DBATCH clean install


If so, how can installing from the identical port used to create the corresponding package be preferable in the absence of customization? It seems like wasted time to me.)

The PACKAGE_BUILDING options are not always identical to the defaults. One is presented with a config dialog(1) for many ports, that one can use to set/unset options, normally not shown in a forum post.
Additionally, I have various variables set in /etc/make.conf, most notably, WITHOUT_NLS=yes, which saves me a bundle of ports depending on gettext. This also doesn't show in 'make clean install', yet changes the result.


I now run RELEASE, recompiling the kernel only in response to security advisories. As a user, my most frequently used applications are plain-vanilla Firefox, Thunderbird, and OpenOffice.org. My impression of these applications is that they are stable, mature, and nontrivial projects. I assume that the default package install options are time-tested to be the "best" for the overwhelming majority of users on a platform-by-platform basis.

And yet, when I still used open-office (I now use Koffice, cause it's just as good and much faster), I compiled my own on a buildserver, cause the package used a threaded perl, that I couldn't use and I didn't want gnome-vfs and did want KDE support.
My KDE uses kdelibs-nocups, so the meta port from FreeBSD is unusable for me. My php5-gd has WITHOUT_X11 set, cause I don't need xorg on webservers, just so php can read an ancient bitmap format, that isn't ever used in webpages.
And so on...


My experience with installing nontrivial applications from ports is that doing so at the very least takes significantly more time than installing from packages, and often causes more problems than I want to be bothered with. About the worst experiences involved installing ports that stomp on shared libraries -- by changing their versions, deleting them, or some other alchemy -- causing a cascade of failures in applications that were working just fine before make install.

Ignorance can only be cured by education. This is what various tools in ports-mgmt/ handle for you and why the /usr/local/lib/compat/pkg directory has been added to ldconfig_paths in /etc/defaults/rc.conf.
Secondly, it's no different when using pkg_add. Upgrading a major version of gettext, through pkg_delete/pkg_add, will screw your installation in the exact same way as pkg_delete/make clean install does.


As far as configuration options are concerned, shouldn't a well designed application provide utilities, configuration files, etc.? Consider FreeBSD itself: we use /boot/loader.conf, /etc/sysctl.conf, /etc/rc.conf, and so on to configure the system. We also use sysctl to customize a running system.

I don't see the relevance of this. Port OPTIONS add/remove features and dependencies, as in, if "OFF", then the feature is not present on your harddisk, ergo you cannot enable it afterwards, similarly, you can only use it if it's "ON". And no - the default is not everything "ON".

[ajh]

Mel_Flynn, thank you for explaining the best reasons for using ports. My view may have been overly simplistic in what I thought was the simplest scenario concerning ports vs. packages.

This is a nuanced, hence subtly complex, topic. This is made all the more complicated when trying to keep systems up to date without breaking anything. I am going to look more deeply at the ports process.

In a plain-vanilla RELEASE environment, is my preference for using packages obtained solely from a FreeBSD ftp site reasonable?

In your experience, are the default options in packages reasonable in my kind of environment?

[liamjfoy]

I've used ports on one machine, packages on another one, and I've also tried mixing them.

Packages are not very up to date. This means that you don't have the latest version of the program, which in it self is not that important, but what is important is the security. Many of the programs I install using packages have already security holes in them. If the programs don't have any holes when I install them, they will sooner or later end up with one or two, and waiting for someone to update that package can take ages. I always have to solve this problem by replacing the package with a port, since they are updated quite fast.

If I don't update the server to the latest version all the time, pkg_add will start having problems finding some of the packages (this can probably be fixed by setting the PACKAGESITE variable). It also seems like many of the mirror serves out there are not really mirrors. They don't have the same packages as some of the other servers.

Ports are always up to date and are updated as soon as a security hole has been found. If I only use ports I rarely see any trouble with my applications or updates I do. If I start mixing, or use packages only I do believe I get more errors and problems than if I had stayed with ports only.


I think its important for new users to know that ports aren't *always* 'up-to-date'. It's a little dangerous to pretend ports solves your security issues regarding software installation and updating - not always the case. You forget the ports rely on maintainers and they are human with finite time :)

[bsddaemon]

Ports all the time! It is such a joy looking at the lovely screen telling you a story with a thousand line of code :D

[marius]

I think its important for new users to know that ports aren't *always* 'up-to-date'. It's a little dangerous to pretend ports solves your security issues regarding software installation and updating - not always the case. You forget the ports rely on maintainers and they are human with finite time :)

You are absolutely right. I should have been more clear when talking about ports always being up to date. Ports are not always up to date and free for security issues, but compared to packages, they are maintained a lot faster, and therefore should be more up to date.

How fast ports are updated will of course depend on the FreeBSD port maintainers.

Sorry, my bad :)

[liamjfoy]

You are absolutely right. I should have been more clear when talking about ports always being up to date. Ports are not always up to date and free for security issues, but compared to packages, they are maintained a lot faster, and therefore should be more up to date.

How fast ports are updated will of course depend on the FreeBSD port maintainers.

Sorry, my bad :)

Agreed :)

[Caliante]

I've read somewhere that noobs should use packages whenever possible; I stick by that rule :e:e:e

[oliverh]

I've read somewhere that noobs should use packages whenever possible; I stick by that rule :e:e:e

Can be a serious pain in the backside, even with stable packages. Apart from that, sometimes you have to use ports for certain functionalities or restricted ports. I wouldn't mix them up, can be okay most of the time, but sometimes it can break your whole installation. Try it ;-)

[hydra]

I use ports most of the time. They are most up-to-date and customizable. I only use packages for very large apps like OpenOffice.

Mixing is possible, it may work, but I had problems with it - that's why I stick to the ports.