From owner-freebsd-questions@FreeBSD.ORG Sat Apr 2 00:51:54 2011 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 739031065670 for ; Sat, 2 Apr 2011 00:51:54 +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 1DCE58FC19 for ; Sat, 2 Apr 2011 00:51:53 +0000 (UTC) Received: from r55.edvax.de (port-92-195-71-79.dynamic.qsc.de [92.195.71.79]) by mx02.qsc.de (Postfix) with ESMTP id 56C3B1E17A; Sat, 2 Apr 2011 02:51:52 +0200 (CEST) Received: from r55.edvax.de (localhost [127.0.0.1]) by r55.edvax.de (8.14.2/8.14.2) with SMTP id p320ppoj012077; Sat, 2 Apr 2011 02:51:51 +0200 (CEST) (envelope-from freebsd@edvax.de) Date: Sat, 2 Apr 2011 02:51:50 +0200 From: Polytropon To: Chris Telting Message-Id: <20110402025150.39722549.freebsd@edvax.de> In-Reply-To: <4D96668C.3090406@telting.org> References: <4D96668C.3090406@telting.org> Organization: EDVAX X-Mailer: Sylpheed 2.4.7 (GTK+ 2.12.1; i386-portbld-freebsd7.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-questions@freebsd.org Subject: Re: Port dependencies 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: Sat, 02 Apr 2011 00:51:54 -0000 On Fri, 01 Apr 2011 16:58:04 -0700, Chris Telting wrote: > Just in a thoughtful mood and thought I'd to the question to the cloud. Oh the joy of cloud computing, erm... discussion. :-) > One of my biggest gripes with the ports system is dependency hell. > Ports link against so my optional components and pull them into the > install. Libraries and components are built based on make file > defines. If you do install a program via pkg_add (it's about precompiled binaries, so no Makefile involved, not even a ports tree), there are also means to determine if something ELSE is needed - as a dependency. Hard disk space is cheap today, so 99% of users don't even bother installing all the stuff they primarily won't need, but the program THAT they need insists on it. > But this doesn't have to be so. It's possible and easy enough > to check a running system for which libraries are installed and only if > a feature is enabled to load the library. It already works that way. Say program A needs B of version n as dependency, then B(n) has to be installed even if B(n-1) is already present on the system. This is no big deal if B isn't installed at all, but requires caution when it is (at version n-1). Of course, B may have other dependencies that do not matter to A, but to B, so even C(m) gets installed. > The number of console > programs that want to pull in X window or kde is my boggling. Hmmm... The only one I remember being that way is the old cvsup, but there was nocvsup-nogui (or -nox11?). > Knowing > how to program myself when I see a "make config" menu on every single > port it makes me want to cry. You can script those mechanism, so you get rid of that interaction and can use file-defined settings. > I think the "make config" menus should > have everything checked by default and only be provided to prevent > things from being compiled such as for embedded devices. Oh no, please - NO! Everything checked by default? That would be problematic for those who, for example, don't WANT to use HAL+DBUS because it just doesn't work for them. Or people who have security concerns (or maybe even external regulations) so they do not want to install something. And remember: Regarding codecs for mplayer and mencoder, it's illegal to listen to MP3 in the US! :-) > My question is why is this so? Why can't programs do more run time > configuration? Is a configuration run time system library needed to > make it easier? You're bringing up an interesting idea, but runtime detection of library (or feature) availability seems to be very time consuming to me. An example is mplayer. On older system, I did always compile it to match the CPU that is present, means NO "runtime CPU detection". Why? Because it often runs too slow on older system if enabled. And let's assume another typical example from the multimedia sector. You have installed mplayer and want to play MP3 audio or an MPEG video file, or even a DVD - which is completely illegal in the US. :-) But there is no libdvd installed, and no MP3 codecs for playing or encoding. What should happen? Upon first start, should the program request you to download and install them? But what if the system is offline? I would assume it's better to install all the stuff needed at install time, no matter if being from ports or as a package. The problem with packages is that most ports have so many options that it would result in 2^x packages if the port has x options. And how should the ports then be named? Should the selected options be abbreviated and in alphabetical order? Well, I would REALLY like to have a USABLE set of options predefined and compiled into the packages. I know that this may very problematic (see codecs), and the packages usually are made using the DEFAULT options which may not be the OPTIMAL options for everyone. And sometimes, there even isn't a package (e. g. OpenOffice) with the required set of options, and even if it is, half of the stuff one assumes is missing (also see OpenOffice). So there is still stuff one needs to compile, and YOU are in charge to define the options you need. This is the "downside" when you're running a multi- purpose OS like FreeBSD. -- Polytropon Magdeburg, Germany Happy FreeBSD user since 4.0 Andra moi ennepe, Mousa, ...