чего ради, собственно ?

Предполагаю, что ради компактности минимального корня с тиклём.

(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