On 22-10-12 22:32, Niels Thykier wrote: > On 2012-07-28 10:16, Paul Gevers wrote: >> In my package I want to create a symlinks to manpages in a recommended >> package (the binaries use update-alternatives to provide the proper >> variant). I would nearly consider this recommended package a dependency >> but doing so would cause a circular dependency and anyway policy [7.2] >> says: > > I think the error would disappear if you were to put the symlink in the > "recommended" package? I appreciate that this may not be as easy as I > make it sound.
The point is I want to prevent duplication of data (the 2 recommended packages could have the same file of course, but that would in case of large data not be nice): winff (in experimental) depends on winff-gtk2 or winff-qt winff contains winff.1 winff-gtk2 and winff-qt both have a symlink to winff.1 winff-gtk2 and winff-qt both recommend winff (to provide menu and man page) >> So I believe that symlinks to recommended packages should be fine, and >> as such the package-contains-broken-symlink check should also consider >> recommended packages next to "depends" packages. >> > > Strictly speaking it would still allow the package to ship a broken > symlink, even if the situation is rare... True. > But I suppose the real question is whether "Recommends is strong enough" > for this purpose... Right. In my case I think it is. I consider the man page very important, but not critical for a package to work. But of course, in the general case for this check it might not be true. Maybe I should just overwrite the Lintian warning. What do you think? Paul
signature.asc
Description: OpenPGP digital signature
