Re: [devel] uncompressed man pages

[REAL <root@mmedia2.kemsu.ru>]

Slava Semushin пишет:
>> Если же всё же подразумевается, что doxygen никто чинить не будет (и файлы
>> Doxyfile ни при чём), может быть, и этот тест репокопа не нужен?
> 
> Если вы думаете, что виноват Doxygen, то повесьте на него багу с
> тест-кейсами и пояснением.

Мне не удалось узнать, по какой причине происходит ломка манов, да и 
не копал сильно, ибо преждевременная ругань на tetex в сборочных 
зависимостях достаёт гораздо сильнее. Впрочем, насчёт trilinos я 
немного поторопился с выводами (либо пока не нашёл те файлы, про 
которые речь в исходном сообщении), здесь doxygen если и виноват, то в 
формировании таких имён файлов, которые не понимает.... кто там 
зажимает маны после сборки? Вероятно, так. Ибо вот пример (имя файла 
страшное, интересно, по какой логике оно формируется, а ведь таких - 
тьма, и намного хуже, чем приведённый):

 > file "/usr/share/man/man3/PHX_ArrayStrideDim_ FortranOrder, Rank, 0 
_.3"
/usr/share/man/man3/PHX_ArrayStrideDim_ FortranOrder, Rank, 0 _.3: 
ASCII troff or preprocessor input text

Но расширение .3, а не нужное .3.gz или .3.bz2.

PS. Помню, что какой-то ман был не-troff, надо будет поискать. А вот 
что касается указанного случая, непонятно вообще, на что и что вешать. 
И уж тем более патчить doxygen я стал бы в одном случае: orphaned в 
репозитории. А пока других дел хватает.

PPS. Вероятно, имеет смысл во избежание ругани вообще отключить 
генерацию манов и оставить только html, но вот лично мне в консоли 
намного удобней смотреть именно маны, а не html в elinks.

-- 

REAL aka Евгений Ростовцев, программист ЦНИТ КемГУ