# Install software, two ways?



## mrutopique (Nov 18, 2013)

Hi everyone, 

I just try freebsd FreeBSD, and when *I* install software there are two ways (according to the tutorial *I* read), `pkg_add` but the software is outdated (Firefox 23, but Firefox 25 is released, for example) or `make install` but *I* stop it after two hours of installing Firefox 25.

Is there a safe way to install updated software in less than hours?

Thanks for your answer.


----------



## Juanitou (Nov 18, 2013)

Have you tried PC-BSD? The last time I installed it for a friend their packages were quite up to date. Official packages have only been made available recently again for FreeBSD (thereâ€™s some threads about it in the forum), the pkg_* tools are being replaced by pkgng and the documentation is not still up to date, so itâ€™s maybe still a tricky moment now for working on FreeBSD with packages instead of ports.

A thread that can provide more insight: Ports, Packages, Oh My!!!


----------



## mrutopique (Nov 18, 2013)

Thanks for your answer, *I* read your link and it seems very difficult to choose an installer to me for now. I may use PC-BSD to begin, the "user friendly desktop Operating System based on FreeBSD" looks like a good choice.

Good to see a UNIX forum that doesn't say RTFM on the first post.


----------



## zspider (Nov 19, 2013)

mrutopique said:
			
		

> Thanks for your answer, *I* read your link and it seems very difficult to choose an installer to me for now. I may use PC-BSD to begin, the "user friendly desktop Operating System based on FreeBSD" looks like a good choice.
> 
> Good to see a UNIX forum that doesn't say RTFM on the first post.



Yeah, who needs a manual when it does it all for you, such a waste of time.


----------



## markbsd (Nov 19, 2013)

mrutopique said:
			
		

> Hi everyone,
> 
> I just try freebsd FreeBSD, and when *I* install software there are two ways (according to the tutorial *I* read), `pkg_add` but the software is outdated (Firefox 23, but Firefox 25 is released, for example) or `make install` but *I* stop it after two hours of installing Firefox 25.
> 
> ...



Don't use `make install`! Don't use it for anything unless a package is not available! It is very time consuming for no, or little, benefit at all.

It's a tough call between pkg_add and pkg, but I'd recommend converting to pkgng:


```
# /usr/sbin/pkg
# pkg info pkg
```

Make sure it is version 1.1.4.


```
# echo "WITH_PKGNG=yes" >> /etc/make.conf
# rm /usr/local/etc/pkg.conf
# mkdir -p /usr/local/etc/pkg/repos
# nano /usr/local/etc/pkg/repos/FreeBSD.conf
```

and input to the file:


```
FreeBSD: {
  url: "http://pkg.FreeBSD.org/${ABI}/latest",
  mirror_type: "srv",
  enabled: "yes"
}
```

then run


```
# pkg2ng
```

Now, to install packages you must forget about ports -- they are a waste of time. And, use `pkg install <package name>`. To locate the name of the package you wish to install you can browse http://www.freshports.org or use `pkg search <package name>`. The latter is a bit useless because obviously you must somewhat know the package name to even search for it.



			
				mrutopique said:
			
		

> Thanks for your answer, *I* read your link and it seems very difficult to choose an installer to me for now. I may use PC-BSD to begin, the "user friendly desktop Operating System based on FreeBSD" looks like a good choice.



FreeBSD can be just as easy as PC-BSD. Just install a DKE immediately after installation. Follow the above process to convert to pkg, then:


```
# pkg install xorg xfce
```

When that completes:


```
# nano /etc/rc.conf
```

and input:


```
hald_enable="YES"
dbus_enable="YES"
```

save and close the file, then:


```
# Xorg -configure
# cp xorg.conf.new /etc/X11/xorg.conf
```

Now, from your normal user account (not root, although do it from root, too, if you will be using Xfce as root):


```
$ echo "/usr/local/bin/startxfce4" > ~/.xinitrc
```

then reboot as root:


```
# reboot
```

login as your normal user, and:


```
$ startx
```

And it will load your desktop environment: Xfce.



> Good to see a UNIX forum that doesn't say RTFM on the first post.



Don't worry, you will get that here too. I think for some people they take offense that you don't read the documentation before asking questions. And they find some smug joy in telling you to RTFM or talk down to you for having not read any documentation. These people are not worth thinking about. But, this place is great because there are some people who will try very hard to help you too. It is still good to read the manual, and also the Handbook, at some stage, but I think it is important for people to help you if they have the knowledge and time to share. Sometimes, reading the man pages, in particular, can make things more confusing if you haven't already received some help and gained some basic experience. Plus, why reinvent the wheel? Learning from others is the most efficient and effective way to do things and you can learn so much more from discussion with more experienced users than going round in circles reading documentation when you don't already have a basic knowledge.

Anyway, trust me, _do not use ports_. You will lose about 750% more time to installing BASIC applications than when using pkg. As you have already experienced with firefox.

I am very new to FreeBSD and seek lots of help myself. But if I can help you with something I will do my best to provide you with accurate and detailed information. Vague answers make things much harder than they need to be.


----------



## Deleted member 9563 (Nov 19, 2013)

markbsd said:
			
		

> Don't use `make install`! Don't use it for anything unless a package is not available! It is very time consuming for no, or little, benefit at all.



I wonder why people do use ports. Especially people who are very knowledgeable about FreeBSD and have been using it professionally for some years. Certainly not because they have more time.


----------



## markbsd (Nov 19, 2013)

OJ said:
			
		

> I wonder why people do use ports. Especially people who are very knowledgeable about FreeBSD and have been using it professionally for some years. Certainly not because they have more time.



I thought about this a lot when I realized I couldn't afford to use ports exclusively after I had decided I wanted to use ports. So, I did a lot of googling, even asked on this forum. I came to the conclusion that it is most likely out of habit, or of a desire to be associated with something more "technical". I received no definitive answer as to the benefit of using ports, or if there is any advantage in using them. You get asked a few questions about whether you want this component or that -- big deal. You might save a few hundred kilobytes or get code that is a few days "newer". That's all. In my completely inexperienced and uninformed opinion, they're the biggest waste of time. One that is completely avoidable too! Ask @wblock@, I know he prefers ports -- I have no idea why though. I think cause he says they're basically "fresher" (in keeping with his sandwich analogy). What that means exactly? I don't know.


----------



## SirDice (Nov 19, 2013)

Packages tend to lag behind a bit, ports are always newer. Plus, if you build from ports you get to enable/disable options. Something that isn't possible with packages. 

Most of us that build ports have ports-mgmt/poudriere or ports-mgmt/tinderbox running on a dedicated machine. That way we don't break running systems by building on them.


----------



## kpa (Nov 19, 2013)

I would argue that it doesn't takes that much extra time to fire up your package building system compared to use of the official packages. If you have set up everything properly it's an almost 100% automated process and you can just `pkg upgrade` your client systems without much thinking. Right now the official packages are built only once a week so even if you build your own packages once a week you're equally up to date on average.


----------



## Juanitou (Nov 19, 2013)

mrutopique said:
			
		

> Thanks for your answer, *I* read your link and it seems very difficult to choose an installer to me for now.



Well, I use on a regular basis:

```
# portsnap fetch update
# pkg updating -d<date>
# pkg version -IvL=
# portmaster <ports>
```

Once youâ€™ve built the first big ports I donâ€™t feel it takes so much time having an up-to-date, customized and stable system.

Also, I think that by building ports regularly you can contribute back to the community, â€œearlier in the pipelineâ€ (sorry, English is not my mother language). Iâ€™ve been able to do it recently and it was really satisfying. Well, using packages doesnâ€™t prevent you for reporting running-time bugs, so I reckon itâ€™s not such a good argument for using portsâ€¦ 

Personal taste and expectations have a big role in choosing how to maintain your computer, I hope youâ€™ll find your way soon, FreeBSD has the advantage too of providing different ways to do it.


----------



## gkontos (Nov 19, 2013)

OJ said:
			
		

> I wonder why people do use ports. Especially people who are very knowledgeable about FreeBSD and have been using it professionally for some years. Certainly not because they have more time.



Because even with pkgng you can not install PHP with the Apache module.

@kpa and @SirDice, having a dedicated machine for building packages is not always a worthy option.


----------



## tzoi516 (Nov 19, 2013)

markbsd said:
			
		

> I thought about this a lot when I realized I couldn't afford to use ports exclusively after I had decided I wanted to use ports. So, I did a lot of googling, even asked on this forum. I came to the conclusion that it is most likely out of habit, or of a desire to be associated with something more "technical". I received no definitive answer as to the benefit of using ports, or if there is any advantage in using them. You get asked a few questions about whether you want this component or that -- big deal. You might save a few hundred kilobytes or get code that is a few days "newer". That's all. In my completely inexperienced and uninformed opinion, they're the biggest waste of time. One that is completely avoidable too! Ask @wblock@, I know he prefers ports -- I have no idea why though. I think cause he says they're basically "fresher" (in keeping with his sandwich analogy). What that means exactly? I don't know.



I mainly use ports to keep current. However, when I get a page full of compile errors that I don't want to deal with for something simple then I go to pkg for the binary, like installing Firefox.


----------



## wblock@ (Nov 19, 2013)

markbsd said:
			
		

> I thought about this a lot when I realized I couldn't afford to use ports exclusively after I had decided I wanted to use ports. So, I did a lot of googling, even asked on this forum. I came to the conclusion that it is most likely out of habit, or of a desire to be associated with something more "technical".



I have found that the benefits of compiling ports outweigh the advantages of binary packages.  (For some reason, this reminds me of when people tell me that inkjet printers "cost less".)



> I received no definitive answer as to the benefit of using ports, or if there is any advantage in using them.



I've posted several.



> You get asked a few questions about whether you want this component or that -- big deal. You might save a few hundred kilobytes or get code that is a few days "newer". That's all.



With ports, you get binaries that are built on your system.  They use the libraries that are present, they build with the processor that will be running them.  It's the difference between tailor-made and buying off-the-shelf.



> In my completely inexperienced and uninformed opinion, they're the biggest waste of time. One that is completely avoidable too!



I've seen more than a few people "saving time" by fighting with binary packages.  Sometimes this goes on for weeks.  In the meantime, systems built from ports are already working.  Yes, it took a while, and yet it took less time overall.



> Ask @wblock@, I know he prefers ports -- I have no idea why though. I think cause he says they're basically "fresher" (in keeping with his sandwich analogy). What that means exactly? I don't know.



Binary packages are (usually) built on someone else's machine.  If your system has the same library versions and the same options as the builder's machine, everything will be fine.  Many times, that does not happen.  Ports do not have that problem, because they are built on-site.


----------



## wblock@ (Nov 19, 2013)

gkontos said:
			
		

> @kpa and @SirDice, having a dedicated machine for building packages is not always a worthily option.



True, it is mostly useful if there are several similar computers that can use the packages.  And of course a package builder must ports, so the admin has both systems to deal with.


----------



## kpa (Nov 19, 2013)

Binary packages would be much more usable now if there was a stable version of the ports tree and clearly defined feature set plus a requirement of binary compatibility between the packages built from that stable tree which is what for example Ubuntu is doing with their package repositories. The FreeBSD ports tree is now "rolling release" which means that any update may break something else. Under a stable ports tree updating to newer versions would be forbidden unless they don't break the feature set and binary compatibility between different components of the stable ports tree. All this might happen with FreeBSD ports but it's going to take lots and lots of work before it's reality. The biggest hurdle will be finding maintainers who can backport security and other fixes to the stable ports tree. It sounds simple but in reality it's a mammoth task compared to the amount of work that a rolling release ports tree requires to keep up to date.


----------



## markbsd (Nov 21, 2013)

kpa said:
			
		

> I would argue that it doesn't takes that much extra time to fire up your package building system compared to use of the official packages. If you have set up everything properly it's an almost 100% automated process and you can just `pkg upgrade` your client systems without much thinking. Right now the official packages are built only once a week so even if you build your own packages once a week you're equally up to date on average.



I've had some ports take in excess of 1-2 hours to compile. The package equivalent took 5 minutes. I think that's a fair bit of extra time. How do you make this process more comparable?



			
				tzoi516 said:
			
		

> I mainly use ports to keep current. However, when I get a page full of compile errors that I don't want to deal with for something simple then I go to `pkg` for the binary, like installing Firefox.



How much more current are the ports compared to packages?



			
				wblock@ said:
			
		

> I have found that the benefits of compiling ports outweigh the advantages of binary packages.  (For some reason, this reminds me of when people tell me that inkjet printers "cost less".)



What, specifically, disadvantages you by using packages?



> I've posted several.



No real end-user benefits to my memory. Just that they're "fresher" or "tailor-made". Quantify this into tangible benefits.



> With ports, you get binaries that are built on your system.  They use the libraries that are present, they build with the processor that will be running them.  It's the difference between tailor-made and buying off-the-shelf.



And? The direct benefit is what exactly? Does the program run noticeably quicker? Do you not need to upgrade as often? If I compile Firefox, for example, from ports, will my browsing experience be better than a package install?



> I've seen more than a few people "saving time" by fighting with binary packages.  Sometimes this goes on for weeks.  In the meantime, systems built from ports are already working.  Yes, it took a while, and yet it took less time overall.



A cursory look at these forums reveals that ports more often than not produce errors. Especially when compared to packages. And *G*oogle results are even more alarming. For your typical desktop user, packages are unquestionably less time consuming in both initial installation and upgrades.



> Binary packages are (usually) built on someone else's machine.  If your system has the same library versions and the same options as the builder's machine, everything will be fine.  Many times, that does not happen.  Ports do not have that problem, because they are built on-site.



I've not had one package that wouldn't install and run on three different FreeBSD machines (except that GNOME problem, but the package didn't exist) that didn't have the same problem as its port counterpart, but I've had multiple programs not compile from ports in the last couple weeks. Sure, this is just my n=1 sample, but, as mentioned, Google returns similar experiences for lots of other people.

I've yet to read or hear of just one quantifiable end-user benefit. If you could establish a significant improvement in running speeds or crash statistics, that would be worth looking at, but no such data exists.


----------



## wblock@ (Nov 21, 2013)

markbsd said:
			
		

> I've had some ports take in excess of 1-2 hours to compile. The package equivalent took 5 minutes. I think that's a fair bit of extra time. How do you make this process more comparable?



The ports I compile generally work without fights.  Packages... well, they want different library versions from other packages.  Or they are compiled without options I need.  Or CPU-intensive programs that could use specific CFLAGS to run faster can't be built into packages, because packages must be built to the lowest common denominator.



> How much more current are the ports compared to packages?



Packages used to be built every 24 hours or so.  I don't know about now.  Ports can be installed as soon as the ports tree is updated.



> What, specifically, disadvantages you by using packages?



See above.



> No real enduser benefits to my memory. Just that they're "fresher" or "tailor-made". Quantify this into tangible benefits.



My applications run and can usually be updated without problems.



> And? The direct benefit is what exactly? Does the program run noticeably quicker?



Some do (thinking of the CPU-specific optimizations in GIMP, for example).



> Do you not need to upgrade as often? If I compile Firefox, for example, from ports, will my browsing experience be better than a package install?  A cursory look at these forums reveals that ports more often than not produce errors. Especially when compared to packages. And google results are even more alarming. For your typical desktop user, packages are unquestionably less time consuming in both initial installation and upgrades.



Let me put it this way: one of us has been fighting with packages for at least a week, maybe longer.  One of us has upgraded a few ports on multiple machines in that same time frame, all of which worked before and after.  Over that time, I have spent more time trying to explain the benefit of ports than I have in actually maintaining them.



> I've not had one package that wouldn't install and run on 3 different FreeBSD machines (except that GNOME problem, but the package didn't exist) that didn't have the same problem as its port counterpart, but I've had multiple programs not compile from ports in the last couple weeks. Sure, this is just my n=1 sample, but, as mentioned, google returns similar experiences for lots of other people.
> 
> I've yet to read or hear of just one quantifiable enduser benefit. If you could establish a significant improvement in running speeds or crash statistics, that would be worth looking at, but no such data exists.



10.4 million results for "FreeBSD package problem", 11.9 million results for "FreeBSD ports problem".

So packages are around 14.4% less trouble.  If you go by sheer number of search results, and certainly that could not be distorted.

One last note, and then I'm going to stop spending time on this: user attitude about upgrades may play a big part.  I upgrade applications whenever an upgrade is available.  Those who prefer to rarely upgrade may do fine with packages.


----------



## markbsd (Nov 22, 2013)

wblock@ said:
			
		

> The ports I compile generally work without fights.  Packages... well, they want different library versions from other packages.  Or they are compiled without options I need.  Or CPU-intensive programs that could use specific CFLAGS to run faster can't be built into packages, because packages must be built to the lowest common denominator.



I've never faced these problems with packages. I have had ports refuse to compile and packages that don't exist. I take it that ports for you, too, take about 750% longer to install than packages. Hard to justify that. The options you don't need, do they make the program run slower? Do they take up gigabytes of extra space? Do these CFLAGS result in less efficient programs? Think not.



> Packages used to be built every 24 hours or so.  I don't know about now.  Ports can be installed as soon as the ports tree is updated.



So, not much difference either way. 



> See above.



Didn't see any disadvantages. Just quicker go-time for packages, which I'm sure 90%+ of users would appreciate. Don't think they're too concerned with CFLAGS or options they don't use.



> My applications run and can usually be updated without problems.



Package installs don't?



> Some do (thinking of the CPU-specific optimizations in GIMP, for example).



So, not really. One example doesn't constitute a whole lot.



> Let me put it this way: one of us has been fighting with packages for at least a week, maybe longer.  One of us has upgraded a few ports on multiple machines in that same time frame, all of which worked before and after.  Over that time, I have spent more time trying to explain the benefit of ports than I have in actually maintaining them.



This is a misrepresentation of the facts. Deliberate? I would hope not. I've been battling with ports -- not packages. The two problems I had with packages -- GNOME and Perl -- existed with ports too 

GNOME did not exist as a package to install. The port failed to compile. But only after wasting my time by compiling for 1.5 hours before crashing with an error! How good is that? +1 to packages... again.

perl was troublesome to update, whether trying to do so with pkg, or by compiling ports. The solution ended up being a pkg solution. +1 to packages.

In the time-frame you mention, Well over three days has been lost to ports. Between updating all ports to failed builds, they've done nothing but cause problems. Packages, not at all. _I d_on't know why you misstate the facts.

_I s_till haven't heard any of these benefits that are realized for the end-user: packages have options turned on you don't need and GIMP runs quicker. Not a whole lot to write home about.



> 10.4 million results for "FreeBSD package problem", 11.9 million results for "FreeBSD ports problem".
> 
> So packages are around 14.4% less trouble.  If you go by sheer number of search results, and certainly that could not be distorted.



So, ports are more troublesome than packages. Sort of what I've been saying.



> One last note, and then I'm going to stop spending time on this: user attitude about upgrades may play a big part.  I upgrade applications whenever an upgrade is available.  Those who prefer to rarely upgrade may do fine with packages.



Basically, there's a whole lot to be gained by using packages over ports. Time being the most valuable.


----------



## Zare (Nov 22, 2013)

@markbsd, 

You are looking from an angle of a desktop user, which is not the FreeBSD target audience.

For instance, a popular Apache2 plus PHP stack comes in two ports on FreeBSD, and about 50 binary packages on Debian's apt. 

pkg_tools and PKGNG both provide only default builds of packages - meaning they are built with preset options. So if you want a php5 Apache module, you're not going to have it using packages because that's not default. Debian, on the other hand, pulls out dynamically loaded objects and repackages them as separate debs. This is not adequate for FreeBSD because it requires too much tinkering with port sources, additional porter work outside of usual scope, unnecessary stress on build infrastructure, etc.

FreeBSD gives you a choice, based on your preference on _using, or not using defaults_. Defaults - packages. Custom - ports.

I'm finding it hard to believe that someone would write, on a UNIX operating system forum, that the ability to control compilation of user packages is overrated over time and convenience. Really. The option to build ports properly is invaluable to system administrators and developers alike. Who are a large majority of FreeBSD's user base.


----------



## kpa (Nov 23, 2013)

The official packages are built only once a week at the moment so the extra time taken to compile everything from ports isn't that much. If the packages were built every 24 hours as they used to be they would be preferable over ports assuming the default options in every package you install are suitable for your purposes.


----------



## kpa (Nov 23, 2013)

We got an explanation why the x11/gnome2 PKG package is missing from the repositories, the graphics/openjpeg happened to be broken at the time the packages were built last wednesday at 1 UTC. Any other ports that depend on that port failed to build as well and the packages didn't go to the repository:

http://lists.freebsd.org/pipermail/freebsd-ports/2013-November/088008.html

This is exactly what I meant with the problems with the rolling release nature of the ports system.


----------

