Xiyue Deng wrote: > However, I am concerned with the maintainability of such a complex > handling that is not blessed by upstream: when there are updates by > adding more info pages or images, and if the package is team > maintained (like racket-mode), other team members may have a hard > time to figure out what to do.
The rule uses globs so it would (theoretically) work if more images/texinfo files come in the future, provided that the images are of the types handled by the rule. It is very far from ideal (and I'm not proud of it all) but it works for my goal: I wanted to ship Info, HTML and PDF documentation and to avoid duplicate files in the .debs. I'm not concerned about the number of team members being able to understand it as there are only two at the time of writing and our team is unlikely to grow (the square world of GNUstep is not so attractive to the masses). Looking at it again, I could avoid those escapes for slashes in the sed invocations if I used "|" or something else as a sed separator. > For now I guess putting the images under /usr/share/info may be the > simplest and supported by most info clients. For manuals only in English and providing only Info variant of the manual, it will work. It doesn't work in my case because fisicalab.app has an English and Spanish manual and the filenames of the images are identical for both languages. It also clutters infodir unnecessarily as info readers have to crawl over more files (and fisicalab.app-doc-(en|es) contain a lot of images). It is also possible to cause file conflicts with images in other manuals having identical names. Also, the fisicalab.app-doc-* packages provide an HTML variant of the manual, so if image files are shiped in infodir then they won't appear in the HTML manual unless specificic patch-work or some sed-fu is being done there (similar to what my rule does). > And if this is acceptable (e.g. documented in the Maintainer's > guide), we may implement this in lintian to be less noisy. For something to be acceptable (generally speaking, or in policy, lintian (lintian follows policy basically), various DEPs, etc.), first it has to be proven to work in practice. Texinfo wrt localization is *very* far from it. There's also a big question what to do with the DIR file in different languages. I had long conversations with the former Texinfo upstream maintainer Karl Berry (a person well known within GNU and TeX communities) regarding this. And this was circa 20 years ago, nothing changed since then. I don't think it's wise to suggest something that will work only for the English language and only for limited cases when there's no HTML variant of the manual.
