Unable to upgrade packages on FreeBSD

[Polytropon]

On Mon, 30 Jan 2012 17:04:56 -0500, David Jackson wrote:
> I wish to use binary packages and I specifically do not want to compile
> anything, it tends to take far too long to compile programs and would
> rather install some packages and have it all work right away.

That's often true, especially when you're low on resources
(CPU speed, disk, RAM).



> Binary
> packages are a big time saver and are more efficient.

More efficient? Depends. In regards of installation, they're
often faster. In regards of spped during operation... well,
depends. :-)

The binary packages are compiled from the ports sources with
the maintainer's default options. Those options might not
perform optimal on _every_ imaginable system. That's why
compiling from source can make programs run faster when
certain optimizations (e. g. specific CFLAGS, selection
of CPU at compile time) are applied. Also functionality
may increase as the default options may leave something
out.

A common example is mplayer: When compiled, it can have
much more functionality and can even work wonders on old
systems. The binary package doesn't give you that.

Other things to keep in mind are language settings. One
example is OpenOffice which needs to have the language
setting at compile time, especially if you're not using
the english language.

Finally, there may be licensing restrictions that forbid
the distribution in binary form, or even the distribution
through the FreeBSD system. Traditional Java may be seen
as an example.



> It should be easy for
> FreeBSD to make it easy to install the most recent versions of all binary
> packages, its beyond belief they cannot pull off such a simple ans straight
> forward, and basic part of any OS.

Again, it depends. The options maintainers define as the
default are typically okay for the build clusters that
process them - they create the binary packages from the
ports tree. At some occassions, options and dependencies
can take into account things that are already installed,
e. g. "foo" uses "bar" if "bar" is installed, but if it's
not installed, it fetches and installs "baz" instead.

Just imagine how many packages you would need to map all
possible combinations of dependencies present, options set
and languages available, and _then_ come up with a naming
scheme for the packages. :-)

I know it is _partially_ possible, or _has been_ in the
past. My famous example here is "pkg_add -r de-openoffice"
to get a full installation of OpenOffice that would work
(fully functional) and even bring a dictionary. With the
newer versions, this easy approach isn't possible anymore.

Just consider X: With or without HAL? With which drivers?
A package plus updates for every possible combination?



> The reason that FreeBSD has a smaller user base is because it has a
> dysfunctional package system and it is hard to upgrade package to the most
> recent version, making FreeBSD more difficult to use/

I do not agree with this statement. The user base of FreeBSD
consists of a major amount of people who do not use the
binary packages, as it seems, because ports work well for
them.

Of course I do not negate the value of the availability of
precompiled packages. In fact, I did use them a lot, but now
that I have sufficient power at home, I feel more comfortable
with building from source. However, I do like the concept of
doing "pkg_add -r <something>" that will install the program
itself and the dependencies if needed, especially for things
that do not need any further tuning.



> But doing a workable package system is not difficult, it something that
> FreeBSD should be easily able to make it easy to have a way to upgrade
> packages to most recent versions out of box anbd in an error free and
> reliable way.

I have named some examples that show how difficult it can get.
That is only for installation. If you consider updating, things
may get a bit more complicated.



-- 
Polytropon
Magdeburg, Germany
Happy FreeBSD user since 4.0
Andra moi ennepe, Mousa, ...