Ports or packages?

C

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.
 
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
 
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.
 
Djn said:
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.
Click to expand...

or use portmaster to install ports
 
Djn said:
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.
Click to expand...

Great tip!
 
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.
 
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.
 
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).
 
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.
 
I'm running an old Plll IBM so I primarily use packages for larger installations like KDE. I'll use ports for smaller programs.
 
How-To?

SirDice said:
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.
Click to expand...

A How-To on this would be nice!
 
Kitche said:
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
Click to expand...

It's a lot less simple then that:
  1. make config-recursive does not catch all cases
  2. When a library is updated, all packages depending on it need to be repackaged.
  3. 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.
 
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.
 
mbs said:
...the compilation allows some configuration for a lot of port. I don't know how to do it with packages.
Click to expand...

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.
 
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.
 
aragon said:
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.
Click to expand...

Bad argument
Code: 
# 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...
 
kamikaze said:
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).
Click to expand...
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.
 
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.
 
I use packages

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.
 
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 ;)
 
hedwards said:
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.
Click to expand...
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:
Code: 
# ---< 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.
 
You must log in or register to reply here.
Back
Top