BSD Philosophy Question: Ports vs pkg_add

Q

Q-Ball

Weaksauce
Joined
Aug 1, 2004
Messages
118
So I'm sitting here at school, bored off my ass and browsing through the FreeBSD handbook (amazing how productive time-wasting can be... ;) ) and suddenly it strikes me: why have both ports and pkg_add? Actually, I like having the choice, being rather impatient with older hardware at times. Forcing you to compile stuff is my one major gripe with running Gentoo on slower hardware; sometimes I'm amazed I've had the patience to stick with compiling everything for as long as I have (PIII-500mhz).

Anyway, I'll probably want to give FreeBSD a shot again one of these days (I still hate not having enough hardware to be able to run all the *nixes I'd like to concurrently). So my question for all the *BSD gurus is this: is it necessarily better to compile all my programs from ports, or does installing binaries via pkg_add not really make any difference in the grand scheme of things?

Just curious to see what people's opinions are...
 
pkg_add gives you the ability to quickly add a fairly recent (maybe not always cutting or bleeding edge) version of a program to your install - it's also pretty easy to uninstall packages. With ports, you can get anywhere up to the bleeding edge of software versions, but the downside is - as you said - it may take quite a while to compile everything you need.

I generally use ports, even on slow machines, instead of packages - in fact I can't really think of one time I did use packages :) Still, it's a moot point for most people - they don't care if they're one sub-version off the latest release of Ethereal or Snort, if they can get the package in a week or two, it's not a big deal.
 
Honestly anymore theres not much of a difference, like the above poster said, sometimes the package may be a minor version behind, because they have to build the ports into packages, and sometimes the queue of stuff to build is behind. Though almost every package I've installed has always been current with the ports.

As far as why to have both, people prefer different things, some like to just install a stable package quickly, and others need to tweak the options and have the time or CPU power to build it from source, or just think building from source is better somehow. When I started using FreeBSD about 7 years ago I used ports since they were considered a "better" build, and a little speed boost if optimized for the system, but anymore I usually just use packages for most things. The only thing I build from source anymore is the world (the core OS itself) during upgrades, and it takes forver + 1 day :D

In short, for the majority of users, packages are perfectly fine. Unless your actually going to give the port non-default options and customize it, you'll really gain nothing from using them. Though install a few small ones just to watch "top" in another term ;)
 
One spiffy thing about it all is you can do a portupgrade and get all fresh code, the latest submitted for the day if you'd like, the downside to this is one or several programs src may be quirky or out of whack, although the next day when fix is likely submitted you can portupgrade just that particular port. I think the major downfall is that once you do a portupgrade you're no longer compatable with the packages collection due to upgraded depencies. This is no bother to me because like UMCPWintermute, I do not ever really use packages just ports. The port collection is great and if you rebuild the kernel with even just a few tweaks like enabling i686 instead of only i386, you'll be miles ahead of where you started.
 
Ports are really useful for building packages as well as installing applications. Packages can be really useful for rolling out in large numbers. If you're running FreeBSD in a corporate environment you'd want to look in to mirroring the package tree for the version of FreeBSD you're using. Then, if you have special software requirements (like you need an application in ports to be built with different options than the defaults) you can build a custom package from ports, put that in your local collection and have it pushed out to all of your machines. It makes life so much easier as far as updates goes.

I would not build ports on every machine in a corporate environment. It's a big time-sink, it creates potential problems and generally isn't a good idea when maintaining a herd of machines.

I do build pretty much everything (except cvsup-without-gui) from ports at home. I have to build things so infrequently it's not much of a big deal to build individual things from ports.

Think of it like this: "I have 1,200 machines here. They all run FreeBSD. Do I want to build ports for everything on all of them, or do I just want to build one package and push it out to all 1,200 of those machines?"

I think the "distributability" of packages is the primary reason for their existance. It helps that you can get a machine up and running quickly with packages, but it really helps in a corporate environment to be able to update and install software automatically in a corporate environment.
 
[H]EMI_426 said:
...if you have special software requirements (like you need an application in ports to be built with different options than the defaults) you can build a custom package from ports, put that in your local collection and have it pushed out to all of your machines. It makes life so much easier as far as updates goes.

I think the "distributability" of packages is the primary reason for their existance. It helps that you can get a machine up and running quickly with packages, but it really helps in a corporate environment to be able to update and install software automatically in a corporate environment.
Click to expand...

That actually makes a ton of sense. Nice to see that kind of flexibility offered to the user.

Although speaking of compiling...any of you BSD users ever compile KDE from scratch? How long did that take?
 
tdg said:
The only thing I build from source anymore is the world (the core OS itself) during upgrades, and it takes forver + 1 day :D
Click to expand...

Woah...I thought building world updated everything. It's just the core? I thought it did packages too. Guess I better get back to reading...
 
buildworld just builds the base system. Ports/pkgs need to be updated using portupgrade.

I've built KDE from ports...Starting from a freshly-installed machine. Took quite a while on my XP1800+...Had to build X.org, Qt, KDE and anything those ports depended on. Not fast, but it worked perfectly. I don't remember how long it took cause I started the build before I went to visit a friend for the weekend and just periodically sshed back to the machine and re-attached the screen to see how the build was doing, if it needed any questions answered, etc.
 
I'll use pkg_add (or usually portinstall -P, so it won't fail if there isn't a package) if I'm impatient, and ports (ok, portinstall) otherwise. I'm experimenting with icc on the laptop right now, and I like to think that it gives a slight speed increase. [1]

KDE takes bloody forever (if you're waiting for it). On the Celeron M 1.4 in the laptop, KDE with a suitable selection of optional packages took many hours, I wouldn't be suprised if it was closer to 8. On a decent stationary computer with more ram it'll be notably faster, but I would still prefer to do it overnight.


[1] With something like the flags I use (-O2 -Ob2 -xB) it'll do interesting things with SSE and MMX; more so than gcc. I don't really expect very big differences, but ... why not.
If anyone wonders, icc is a suprisingly easy replacement for gcc. Recompile libtool15 and libtool17, and almost everything will make fine with it. It produces a huge amount of warnings (it's much more picky than gcc), but usually works.
 
Is there anywhere I could find a guide on getting the icc working as the system compiler? Some googling revealed it is the Intel C Compiler..but that's about it. Really, it's not that surprising given that logically, a lot of open-source users would shun the use of a closed-source compiler.

The most recent (lengthy) discussion I could find on the subject was in this thread at BSD Forums, but the discussion is about 2 years old. Are there still issues with things such as NFS that were mentioned in that thread?

Also, would compiling with icc provide as much benefit being used on an AMD cpu vs. an Intel platform? I'd assume it would provide at least some benefit, given that it's all the same basic IA-32 architecture, but you never know.

I fully expect to break the system a time or two figuring this out, but I'd still like to experiment :) .

*Edits for spelling and wrong link*
 
On an AMD platform, it's notably less good. (It's tied very strongly to their modelling of their own CPUs, more so than what's strictly neccesary).
I'd still suggest trying, if you're able to find some suitable benchmark you can see if it's an improvment. Besides, it's a nice tool for debugging C, it has better error messages than gcc.

Basically, install lang/icc and follow the instructions. (You'll need to make yourself a free account with intel and download a file manually.)
I think it puts its binaries in a directory not in the default PATH, though I could be wrong.
To use it for ports and buildworld, you have to add/change a few lines in /etc/make.conf.
(I have to boot the laptop in FreeBSD to give you the details, so they will have to wait a bit.)
 
No particular hurry, since I don't even have FreeBSD installed on anything at the moment. With school and all, I haven't had much time to experiment of late. Although I may wipe the slate clean on my test system this weekend, since I'm kinda getting the BSD itch back...
 
Yeah, sometimes I get the OS itch...I get the urge to run like 5 distro's of linux and run both FreeBSD and Desktop instead of deciding on one....My spare box's have some great hd's and have somehow stood up to this abuse for over 3 years now :D
 
hitman_forhire said:
Yeah, sometimes I get the OS itch...I get the urge to run like 5 distro's of linux and run both FreeBSD and Desktop instead of deciding on one....My spare box's have some great hd's and have somehow stood up to this abuse for over 3 years now :D
Click to expand...

I know what you mean. :)
I've quadbooted windows 98, qnx, BeOS and linux earlier. (Can't remember if I put win2000 on it, too. The bootloader got a bit crowded.)
 
hitman_forhire said:
Yeah, sometimes I get the OS itch...I get the urge to run like 5 distro's of linux and run both FreeBSD and Desktop instead of deciding on one....My spare box's have some great hd's and have somehow stood up to this abuse for over 3 years now :D
Click to expand...

If I had a larger hard drive to play with on my *nix box (only 10 gigs right now), I'd probably see how far I could push Grub and partitioning. :D

Actually, speaking of bootloaders, I rather like the FreeBSD bootloader...I think that's about as simple as it gets. And l like simplicity. :)
 
Q-Ball said:
If I had a larger hard drive to play with on my *nix box (only 10 gigs right now), I'd probably see how far I could push Grub and partitioning. :D

Actually, speaking of bootloaders, I rather like the FreeBSD bootloader...I think that's about as simple as it gets. And l like simplicity. :)
Click to expand...

Yeah, it's quite nice. Nothing to configure, and it's not dependant on any other partitions.
I also liked the BeOS bootloader: Better-looking, and configurable from a nice GUI (in BeOS) if you wanted to. (Mostly used for dropping the timeout to 3 seconds, renaming the items, and pruning the non-functional ones.). It didn't contain any BeOS-specific loading code, and didn't depend on having a working BeOS partition.

edit: It's also completely impossible to find a screenshot of. The GUI tool, yes. The BeOS boot settings, yes. But not the actual boot manager. :)

If I had unlimited spare time, my alpha would triboot OpenVMS, Tru64 and FreeBSD, I'd have the O2 up and running (perhaps with NetBSD on a secondary disk), and I'd install solaris x86 again. :D
 
You must log in or register to reply here.
Back
Top