Предлагаю файлы ChangeLog и changes за-bzip-ить и перенести в субпакет tcl-devel, а %_mandir/mann/* - вынести в отдельный субпакет (скажем, tcl-devel-man - noarch)
чего ради, собственно ?
Предполагаю, что ради компактности минимального корня с тиклём.
(In reply to comment #1) > чего ради, собственно ? Потому как мануалы для разработчика не совсем уместно таскать в runtime-пакете, так же как и чейнжлоги. По-хорошему, *.msg тоже неплохо бы паковать с префиксом %lang(xx)
lang для msg - согласен, ChangeLog -- тоже. С остальным --нет, ради экономии восьмиста килобайт я не стану изменять устоявшийся попакетный расклад и затруднять доступ к документации, мало отличающейся от bash builtins (имея ввиду область применения)
(поразмыслив) --excludedocs вас не спасло бы ?
(In reply to comment #5) > (поразмыслив) > --excludedocs вас не спасло бы ? Ну, поняв, что вы "категорически против" я на крацний случай сделал для себя заметку: apt-get install -o RPM::Options::--excludedocs foo Жаль, что не получится уменьшить arch-специфичную часть пакета, но... "на нет и суда нет":)
Ты spec diff привесь и цель сформулируй, будет над чем торговаться. :)
Created attachment 2778 [details] tcl.spec.diff Пожалуйста - "spec diff". Ещё один вопрос (сорри, если глупость): *.enc точно libtcl не нужны?
я мог бы (предположим) вынести маны в подпакет, но тут же написал бы в tcl requires: tcl-devel-man -- сомневаюсь, что вас это устроит. затем, я с недоверием отношусь к возможности получать noarch/arch пакеты из одного исходника и не планирую пользоваться этой возможностью в обозримом будущем. anyway, моя позиция состоит в том, что /usr/bin/tclsh и маны должны ходить вместе, я не намерен её изменять; желание сэкономить 800к при ~2M содержимого /usr/share/tcl указывает на некие специальные условия, а значит, и решения должны быть специальные, вроде --excludedocs. wrt .enc: формально -- зависимости нет. я вполне могу представить себе некий бинарник, слинкованный с libtcl и использующий оттуда какие-то функции как в голову взбредёт.
(In reply to comment #9) Я не собираюсь вас в чём убеждать или разубеждать - мне это неинтересно и базилла не то место, где это следует делать:) > wrt .enc: формально -- зависимости нет. > я вполне могу представить себе некий бинарник, слинкованный с libtcl > и использующий оттуда какие-то функции как в голову взбредёт. Вам виднее. Я просто хотел уточнить: нет ли в libtcl.so функций, которые для своей работы предполагают наличие *.enc? Т.е. я могу быть спокоен, что, например, в qtcl (он слинкован с libtcl8.5.so, зависит от libtcl) функции перекодирования будут работать корректно без установленного пакета tcl?
разумеется, такие функции в libtcl есть. как зависит работоспособность qtcl от их наличия/отсутствия, я судить не берусь.
(In reply to comment #11) > разумеется, такие функции в libtcl есть. > как зависит работоспособность qtcl от их наличия/отсутствия, > я судить не берусь. qtcl - это аналог wish, только с Qt вместо Tk. Т.о. я понял, что работать не будет... Тогда прошу перенести *.enc в libtcl (или отдельный багрепорт завести?) или вынести *.enc в отдельный субпакет libtcl-enc, установив в libtcl зависимость на него. Также прошу, всё же, рассмотреть возможность вынесения mann в отдельный пакет, чтобы не было необходимости тянуть пакет tcl, если предполагается использование shell'ов, отличных от tclsh (wish,qtcl,ktcl,qtcl4,etc.)
вообще-то, на этот счёт (qtcl, .enc и пр) следовало бы открыть другой баг. кратенько тут: вносить .enc в libtcl не стану, поскольку по той же логике туда бы следовало отнести всё содержимое /usr/share/tcl/tcl8.x; действительно, библиотека libtcl содержит функции, работоспособность которых зависит от наличия этого самого содержимого (в сущности, это основная часть библиотеки, если не по объёму, то по востребованности, начиная с Tcl_Init). таким образом, корректной реакцией было бы внесение libtcl обратно в tcl и упразднение подпакета libtcl. что касается qtcl/ktcl: в нынешнем состоянии они противоречат рекомендациям по сборке tcl-расширений, изложенным в /usr/share/doc/rpm-build-tcl-0.4/README.layout, а именно - наличие custom tcl shell; - невозможность использовать предоставляемую ими функциональность в обычном tclsh/wish. и, таким образом, я не считаю себя обязанным учитывать их существование.
(In reply to comment #13) > и, таким образом, я не считаю себя обязанным учитывать их существование. no comment
