Wouter Verhelst <wou...@debian.org> writes: > On Thu, Mar 09, 2017 at 10:19:10AM -0800, Russ Allbery wrote:
>> Now, if this were taken a further step so that dpkg-shlibdeps would >> provide some mechanism to *automatically* add those downstream >> dependencies to packages that depend on the library unless the >> dependencies were explicitly suppressed, I wouldn't be as strongly >> opposed. > I think this is probably the best way forward, and it doesn't even need > to be too complicated: > - Modify dpkg-shlibdeps so it supports the type "opt" in the shlibs file > (see "man deb-shlibs" for details); > - Make dpkg-shlibdeps emit the conjunction of the regular shared library > dependencies (i.e., typeless dependencies) and the "opt" type ones > (the daemons etc that the library would need if used) in the > ${shlibs:Depends} substvar, if no special command line parameter was > passed to it; > - If a special command line was passed to it of the form > "--suggests=libfoo0,libbar0" or "--recommends=libfoo0,libbar0", then > pass the optional dependencies for the given packages in new > ${shlibs:Suggests} or ${shlibs:Recommends} substvars instead (and pass > any optional dependencies for packages not so given still in the > ${shlibs:Depends} substvars). > With that, maintainers who consume libraries but don't do anything > special will continue to produce working packages; and maintainers who > consume libraries and care can use ${shlibs:Suggests} and > ${shlibs:Recommends} substvars to decide where the optional dependencies > must go without breaking anything for users. Yeah, I'm kind of coming around to something like this, although I suspect you'd need more granularity than just one pair of variables, at least eventually. But that's an implementation detail. I think it's worth remembering, though, that this is unlikely to change anything about the particular use case that triggered this whole thread. I don't want us to lose track of the fact that the canonical example (upower -> usbmuxd via a library for Apple support) isn't a mistake or accident; it's a tradeoff disagreement between people with different preferences about what the ideal state should look like. If we put in place this mechanism or something like it, I fully expect that the upower maintainer would think "hm, actually, I want my package to work on Apple hardware out of the box without requiring anyone do something special, particularly since otherwise I get bug reports about it not working on that hardware, so adding the Recommends that brings in usbmuxd looks correct -- if people don't like it, they can always remove it or turn off Recommends." And then we would be back to exactly where we are right now. We should make sure that we're actually solving a real problem here before doing work, which includes being sure that a solution, if implemented, would actually change things. I continue to think that the disagreement isn't a theoretical one over how to handle library to binary dependencies, but an actual technical disagreement over the importance of out-of-the-box hardware support versus system bloat when Recommends is enabled. We're not going to resolve that disagreement by writing more Policy or more code in dpkg-shlibdeps. (That said, the above system seems rather neat to me.) -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>