Date: Mon, 30 Jan 2012 18:40:50 -0500 From: David Jackson <djackson452@gmail.com> To: Polytropon <freebsd@edvax.de>, freebsd-questions@freebsd.org Subject: Re: Unable to upgrade packages on FreeBSD Message-ID: <CAGy-%2Bi-bwgvf9UbMq0zUqPSzqPGcf%2B=Dv1pncbsL2AW6=80niA@mail.gmail.com> In-Reply-To: <20120130234946.e2747081.freebsd@edvax.de> References: <CAGy-%2Bi-6GLfoUuhUExjnVEKhM00TuUimhKuhboLkjBeXNk9hFg@mail.gmail.com> <20120130215826.140fa9df@mpw> <CAGy-%2Bi9pYgB3VjG8KQg98Bfr5Ax2BOLOnuqrzOe_P5juDe%2BVjw@mail.gmail.com> <20120130234946.e2747081.freebsd@edvax.de>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Jan 30, 2012 at 5:49 PM, Polytropon <freebsd@edvax.de> wrote: > 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. > > That is true. Well, unless is a problem with cross CPU compatability, all available options should be compiled in by default. Mplayer (or it was some video players) has a huge number of display targets for instance, they can be runtime selected so support for all of them can be compiled in my default and the user can then select which one to use at runtime. I have used video player where you can choose between OpenGL, plain X11, Xvideo, and many other display options and I actually liked having these kinds of runtime choices. A package for these programs can be provided and if a user needs a compile time option they can then spot compile them as needed. > 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. > > You could compile a version of that for each language and I think thats what Ubuntu does, or, just compile maybe top 1 or 2 most commonly used language version and then other versions could be user compiled. > 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. > > > This is rare, but it happens. Most programs dont have this problem. a few programs must be compiled like this, it is a lot easier to compile that handful of programs for me than it is to compile the entire system. > > > 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. :-) > > Just compile package for the package download site with all optionals and functionality available. If it has optional dependancies, just install all of the dependancies when the package that needs them is installed. Then user can has all features avialable at runtime. If its an one or the other type option, compile with the most commonly used setting. In many cases they use run time options in programs so this is not as much of an issue in those cases. if people want to make their own compile time options then they can resort to compiling the package themselves. 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? > > > Probably throw in all options at compile time for packages, such as HAL, and then it will be available if people need to use it. If people dont want a component, then they compile on their own. As far as dependancies, the program can be compiled to rely on them and they would be installed automatically when the depending application is installed. Im not sure what HAL does but Ive installed it for X Window System, if it makes it work better, I have no problem with installing HAL. > > 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. > > Perhaps that is because the people who want to use packages have given up on FreeBSD. -- > 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?CAGy-%2Bi-bwgvf9UbMq0zUqPSzqPGcf%2B=Dv1pncbsL2AW6=80niA>