Dnia 2014-07-21, o godz. 13:23:46 Thomas Kahle <[email protected]> napisał(a):
> the OCR software tesseract has many different plugins for > language packs used for OCR for different languages. The ebuild > uses the LINGUAS variable to pass the choice of which packages to > install to the user. > > A reverse dependency is app-text/pdfsandwich which roughly puts > OCR'ed text in a scanned pdf. Since it uses tesseract it > supports exactly those languages that tesseract supports. Do I understand correctly that pdfsandwich doesn't have any explicit switches for language support? In other words, adding support for another language requires rebuilding tesseract and not pdfsandwich? > Should its ebuild have LINGUAS use flags and then depend on > tesseract with at least those flags set? > > While it seems consistent to put the LINGUAS choice in the most > user facing package, in this case I would actually not put it in > here. It would introduces a point of failure and maintenance > work for the each tesseract upgrade (since the language set > slightly changes from time to time). A typical user would set > LINGUAS in her make.conf anyway. In this case the same choice > applies to both packages anyway. Maybe an einfo is sufficient to > inform the user it? I have no idea where did you get the 'most user facing' idea from but this is not really true or useful. The whole idea of libraries like imagemagick is about hiding unnecessary dependencies under single interface -- now imagine every package using imagemagick declaring flags for all the formats supported by it... If pdfsandwich itself doesn't do anything with LINGUAS, don't declare it. The rule about USE flags not doing anything applies here. Moreover, LINGUAS are usually set globally so scope is not really an issue here. -- Best regards, Michał Górny
signature.asc
Description: PGP signature
