Le Thu, May 03, 2012 at 12:39:04PM -0400, Joey Hess a écrit : > > Consider a package that contains a node.js script, which is not the > primary purpose of the package. So it Recommends, rather than depends > on nodejs. (Let's assume it uses #!/usr/bin/env node, and for the sake > of example is something root might run, so /usr/sbin could be in PATH.) > > Using Conflicts makes this script behave very unfortunatly in certian > circumstances. If some third package came along and added another node > binary, and conflicted with node.js, we would probably call that package > RC buggy, as it breaks unrelated software. So, having conflicting > packages of this sort makes using Recommends, or even Suggests, a > minefield, and should be avoided.
This is a good point, but on the other hand there is the alternative conclusion that it argues for using Depends instead of Recommends, or moving the script out of the default path. If the program were not a script but a binary that is linked to a library, I think it would be considered to be a bug to only recommend that library even if the program is not important. Dependance on an interpreter is not that different. While the scenario for breakage that you gave is quite a corner case, the general situation, to have in a package some accessory programs for which we are reluctant to depend on everything they need (python, ruby, etc.), is quite frequent. I would welcome some guidelines here. Perhaps we are too shy creating accessory packages that contain only a few files ? I do not remember seeing a quantitative evaluation of what is the cost of adding a small package to the pool. Cheers, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120504140912.gb8...@falafel.plessy.net
