Date: Mon, 30 Jan 2012 23:49:46 +0100 From: Polytropon <freebsd@edvax.de> To: David Jackson <djackson452@gmail.com> Cc: freebsd-questions@freebsd.org Subject: Re: Unable to upgrade packages on FreeBSD Message-ID: <20120130234946.e2747081.freebsd@edvax.de> In-Reply-To: <CAGy-%2Bi9pYgB3VjG8KQg98Bfr5Ax2BOLOnuqrzOe_P5juDe%2BVjw@mail.gmail.com> References: <CAGy-%2Bi-6GLfoUuhUExjnVEKhM00TuUimhKuhboLkjBeXNk9hFg@mail.gmail.com> <20120130215826.140fa9df@mpw> <CAGy-%2Bi9pYgB3VjG8KQg98Bfr5Ax2BOLOnuqrzOe_P5juDe%2BVjw@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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, ...
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20120130234946.e2747081.freebsd>