(Very) bogus package dependencies
avg at icyb.net.ua
Mon Dec 24 06:23:27 PST 2007
Paul Schmehl wrote:
> --On Monday, December 10, 2007 16:33:20 +0200 Andriy Gapon
> <a... at 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.
More information about the freebsd-ports