Rene Engelhard wrote: > Sven Luther wrote: >>Or you could try a shlibs override. look at dpkg-shlibsdep manpage for >>more details. > Or you just kick the first xlibs out using sed :) Given the fact that - There is no policy reference in the Lintian output, (Though I may have overlooked the item in policy to specify this.) - The explanation "can break some tools" is rather soft... - ... especially when there are approximately 307 other packages that would break the same tools, - The bug is not in the package and is "self-fixing" as far as the package itself is concerned, - The bug would have been fixed in dpkg-shlibdeps and/or xlibs if anyone cared enough, it may be argued that all you're doing is a "my package has zero or less lintian errors" beauty contest, at least partially with *dubious* methods: Both of your suggestions cause unneccessary problems when backporting packages which use it. Especially with the sed method, you're not removing an incorrect dependency: You unconditionally remove a depencency, which is a bug in itself, unless, of course, you specify a build-dependency on xlibs (>> 4.2.0). (And no, I'm not suggesting the latter.) That type of hack may be justified when the problem you cure is more grave than the side effects, but given that people are porting packages. > - who wonders why people don't read the archives; this issue came up already > a few times... For the individual that's because (# of issues * probability that I forget to search or overlook something)>0 and for the issue (# of people * probability that a random person does the same thing)>0. Thomas - who recommends looking at pollen of plants in liquids to people who want something that doesn't repeat itself
Attachment:
pgpeiEn5wXKAF.pgp
Description: PGP signature