From owner-freebsd-ports@FreeBSD.ORG Mon Dec 10 19:10:49 2007 Return-Path: Delivered-To: freebsd-ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1247616A46C for ; Mon, 10 Dec 2007 19:10:49 +0000 (UTC) (envelope-from beech@freebsd.org) Received: from freebsd.alaskaparadise.com (freebsd.alaskaparadise.com [208.79.80.117]) by mx1.freebsd.org (Postfix) with ESMTP id BEED013C4E7 for ; Mon, 10 Dec 2007 19:10:48 +0000 (UTC) (envelope-from beech@freebsd.org) Received: from 137-42-178-69.gci.net (137-42-178-69.gci.net [69.178.42.137]) by freebsd.alaskaparadise.com (Postfix) with ESMTP id 6A08423835A9; Mon, 10 Dec 2007 19:10:47 +0000 (UTC) From: Beech Rintoul To: freebsd-ports@freebsd.org Date: Mon, 10 Dec 2007 10:10:33 -0900 User-Agent: KMail/1.9.7 References: <475D4E30.2030403@icyb.net.ua> In-Reply-To: X-Face: jC2w\k*Q1\0DA2Q0Eh&BrP/Rt2M,^2O#R07VoT98m*>miQF9%Bi9vy`F6cPjwEe?m,)=?utf-8?q?2=0A=09X=3FM=5C=3AOE9QgZ?="xT3/n3,3MJ7N=Cfkmi%f(w^~X"SUxn>; 27NO; C+)g[7J`$G*SN>{<=?utf-8?q?O=3Bg7=7C=0A=09o=7D=265A=5D4?=@7D`=Eb@Zs1Ln814?]|k@'bG=.Ca"[|8+_.OsNAo8!#?4u MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200712101010.41652.beech@freebsd.org> Cc: Paul Schmehl Subject: Re: (Very) bogus package dependencies X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Beech Rintoul List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Dec 2007 19:10:49 -0000 On Monday 10 December 2007, Paul Schmehl said: > --On Monday, December 10, 2007 16:33:20 +0200 Andriy Gapon > > wrote: > >> From a small research it seems that the only thing needed from > >> cdrtools > > > > is isoinfo utility which gets called in FreeBSD-specific code > > (hald/freebsd/probing/probe-volume.c) like follows: > > isoinfo -p -i %s > > And it seems that its only usage is to detect presence of > > directories named 'VIDEO_TS|VCD|SVCD', so that properties like > > volume.disc.is_videodvd could be set. > > > > Maybe there is a way to write code for this functionality that > > could be included into hal source code or as a port patch, so > > that hal doesn't have to depend on cdrtools. > > While I have no objections to this particular suggestion, my > question would be - where do you stop? You could easily do this > for hundreds (if not thousands of ports) that depend upon some > other port because of one piece of code. > > In general. port maintainers follow the guidelines of the software > developer. If the developer states that the software depends upon > cdrtools, then the maintainer is going to include that dependency > in the port. Many of us don't have sufficient skill to audit code > and determine where a dependency could be replaced by some > additional code. > > So, while this might make sense in isolated cases, I don't think it > scales well. Furthermore, modern machines generally have enough > disc space that the addition of a few "unused" ports to include > necessary code is a small price to pay to distribute the load of > providing ports over a larger population of volunteers. (And yes, > I know not everyone has a modern machine or large discs to work > with.) I agree. The ports tree is a moving target. Any time you add custom code to a port it puts you (as maintainer) in the position of being both developer and maintainer. Frequently building a port will pull in dependencies all of which are maintained by different people. We already run into the problem where updating port foo requires port bar be updated first. Fortunately, there is a lot of cooperation by those on the project and it's rarely an issue. However, adding dependent code into the port itself would make this situation an absolute nightmare. Instead of maintaining one port, now you're maintaining two or more (not to mention license issues). We already have ports in the tree which download and extract other ports, but only use a specific piece. These tend to all be from the same master port or family. If disk space is a premium common tools like autotools can be removed after the port is built, but doing that will quickly paint you into a corner where you no longer have the space to build. We have options in ports that frequently determine if a dependency will be built or not depending on choice. It's up to the individual maintainer to include options. Many ports have additional options which can be set (or unset) from the command line. We tend to include the most common options, but that doesn't mean others aren't available. Anyone with interest at this level is strongly encouraged to read the port's Makefile before building and installing. -- --------------------------------------------------------------------------------------- Beech Rintoul - FreeBSD Developer - beech@FreeBSD.org /"\ ASCII Ribbon Campaign | FreeBSD Since 4.x \ / - NO HTML/RTF in e-mail | http://www.freebsd.org X - NO Word docs in e-mail | Latest Release: / \ - http://www.FreeBSD.org/releases/6.2R/announce.html ---------------------------------------------------------------------------------------