Date: Mon, 24 Dec 2007 16:23:15 +0200 From: Andriy Gapon <avg@icyb.net.ua> To: freebsd-ports@freebsd.org, Paul Schmehl <pauls@utdallas.edu> Cc: freebsd-gnome@freebsd.org Subject: Re: (Very) bogus package dependencies Message-ID: <476FC0D3.2090106@icyb.net.ua>
next in thread | raw e-mail | index | archive | help
Paul Schmehl wrote: > --On Monday, December 10, 2007 16:33:20 +0200 Andriy Gapon > <a...@icyb.net.ua> 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.) You are certainly correct from a general port maintainer's point of view. I was speaking rather from a programmer's point of view and on a specific subject. Typically you don't add a dependency for an external large product that can do what you need plus a million other things if you can do what you want in a small block of code. Also, while your point is true in general, general approaches are not necessarily the best for some cases (especially if the case is in the focus). HAL belongs to a certain subcategory of ported software where there is a substantial FreeBSD-specific body of code. Dependency on cdrtools came not from Linux-specific code or common code, it came exactly from FreeBSD-specific code. And in cases like this, port maintainer is usually a maintainer of FreeBSD-specific code. And even if not, those two should be in close touch with each other. Even from a maintainer's point of view it is not a best approach to introduce such a dependency because you never know how it can come around to bite you. We can imagine a case where cdrtools grow a dependency on HAL for hardware identification, in this case we would end up with a circular dependency. This is a weak example, but I hope that it demonstrates the idea. And a practical thought: it seems that in recent FreeBSD versions system tar can work rather well with the ISO CD9660 FS, so it should be enough to list directories in an image. What I am trying to say: before adding a dependency examine your options and choose the best one. -- Andriy Gapon
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?476FC0D3.2090106>