From owner-freebsd-questions@FreeBSD.ORG Wed Mar 7 16:59:00 2012 Return-Path: Delivered-To: freebsd-questions@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id ADCBE1065670 for ; Wed, 7 Mar 2012 16:59:00 +0000 (UTC) (envelope-from freebsd@edvax.de) Received: from mx02.qsc.de (mx02.qsc.de [213.148.130.14]) by mx1.freebsd.org (Postfix) with ESMTP id 425D78FC08 for ; Wed, 7 Mar 2012 16:59:00 +0000 (UTC) Received: from r56.edvax.de (port-92-195-185-71.dynamic.qsc.de [92.195.185.71]) by mx02.qsc.de (Postfix) with ESMTP id 62F1E1E3C3; Wed, 7 Mar 2012 17:58:52 +0100 (CET) Received: from r56.edvax.de (localhost [127.0.0.1]) by r56.edvax.de (8.14.5/8.14.5) with SMTP id q27GwqNf002199; Wed, 7 Mar 2012 17:58:52 +0100 (CET) (envelope-from freebsd@edvax.de) Date: Wed, 7 Mar 2012 17:58:52 +0100 From: Polytropon To: David Jackson Message-Id: <20120307175852.7de93d6f.freebsd@edvax.de> In-Reply-To: References: Organization: EDVAX X-Mailer: Sylpheed 3.1.1 (GTK+ 2.24.5; i386-portbld-freebsd8.2) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-questions@freebsd.org Subject: Re: Still having trouble with package upgrades X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Polytropon List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Mar 2012 16:59:00 -0000 David, allow me to add a few thoughts: On Wed, 7 Mar 2012 11:28:47 -0500, David Jackson wrote: > As for compile options, the solution is simple, compile in all feature > options and the most commonly used settings into the binary packages, for > the standard i386 CPU. I think this can develop into a major problem in certain countries where listening to MP3 is illegal. :-) However, when considerations of law enter the field, the problem becomes obvious: There are situations, depending on local national law or software licnsing, when it is not possible to include certain functionality by default. You know, I'd _love_ to "pkg_add -r mplayer" to get mplayer and mencoder with _all_ the codecs so it can play everything. Sadly, that is not the default situation. You can also encounter similar "barriers" with Linux when you install a distribution, and many things work out of the box, but as soon as you "cross a certain line" (i. e. you want to access specific media formats), you need to add something to your installation. That shouldn't be neccessary, and it is not neccessary from a technical point of view, but legal objections seem to demand it it's artificially made impossible... > If people want customisations then they can build > the software for themselves. That's what they'll do anyway. :-) Especially on systems low on resources, compiling from source is _the_ way to squeeze every required (!) bit of performance out of code. Even if compiling may require some time (due to optimization flags), the result can be really usable. > When a new kernel is released, there is no reason to reinstall all of the > packages on the system at the same time. Since the kernel and userland > packages have different development cycles, there is no reason why there > has to be synchronization of the upgrading. It sometimes is neccessary, for example if kernel interfaces have changed. There is some means of compatibility provided by the compat_ ports. But if you start upgrading things, libraries can break, and the system may become unstable (in terms of not being able of running certain programs anymore). Just see how "kernel and world are out of sync" errors can even cause the system to stop booting. Degrading the inner workings of the OS to "just another package" can cause trouble. "Simple updates" as they are often performed on Linux systems can render the whole installation totally unusable because "something minor" went wrong. :-) > An OS that requires a user to reinstall > everything just to upgrade the kernel is not user friendly. Why do consider a user being supposed to mess with kernels? This question can show that I'm already too old: Programs are for users, kernels are for sysadmins. Sysadmins do stuff properly, even if they shoot their foot in order to learn an important lesson. :-) As I said before: Updating the kernel _may_ cause many "dependency programs" (the userland and often the installed 3rd party applications) to become target of updating in order to keep their functionality. New kernel interfaces, changes in ABI or API, new libraries, as well as obsoleted things may be a valid (!) reason. -- Polytropon Magdeburg, Germany Happy FreeBSD user since 4.0 Andra moi ennepe, Mousa, ...