Неправильный перевод кодировок в новом rpm

[ruslandh]

Выставляйте баги, прикладывайте патчи, убеждайте каждого мантейнера, что это нужно - это ваше право.

Ну чесслово не смешно.
А потом во всех багрепортах эту ссылку раздавать и в 2017-ом убеждать мейнтейнера переходить на utf8?
https://www.altlinux.org/SampleSpecs/program

Главное не спешить.

[ruslandh]

https://www.altlinux.org/SampleSpecs/program

Это вообще не аргумент

[stranger573]

Затем чтобы ненужный зоопарк не разводить.

Это не рациональный и очень трудоёмкий путь - ради бага в rpm менять  и пересобирать 400 пакетов, тем более, что нет никакой гарантии, что они пересоберутся.

Шутка?
При сборке спек уже открыт — посмотреть, проверить, изменить, причём это всё равно делается независимо от обсуждаемой пробемы. Дополнительно только меняем несколько символов в "%description -l", если несколько таких строк — копипастой. Сохраняем в целевой кодировке. Финита комедия ля. Вы это трудоёмкостью называете? При всех последующих сборках уже ничего делать не надо.
Нерационально было изначально делать в чужеродных кодировках.

ради бага в rpm менять  и пересобирать 400 пакетов

Не ради бага в rpm, а ради исправления ничем не оправданных предыдущих действий при написании спеков.
И никто не требует разом все 400. Всего лишь, собираете новую версию пакета или пересобираете старый пакет — поправьте спек. Собираемость от этого вряд-ли ухудшится.

С патчами хуже. Патч навеки будет болтаться в исходном пакете, и его при каждом изменении спека (а это происходит каждый раз) надо будет переделывать. Патчи как раз только усугубят проблему.

[Speccyfighter]

https://www.altlinux.org/SampleSpecs/program

Это вообще не аргумент

А что тогда аргумент при отсутствии полиси? Разносортная мозаика кодировок дескрипшн?
Не факт же что rpm снова не сломается, кода без ошибок не бывает. Так оно будет из раза в раз повторяться. Но зачем?

[ruslandh]

А что тогда аргумент при отсутствии полиси?

Правила написания spec

[ruslandh]

https://www.altlinux.org/Особенности_написания_спек_файлов_в_ALT_Linux
https://www.altlinux.org/ALT_Packaging_HOWTO

[Speccyfighter]

А что тогда аргумент при отсутствии полиси?

Правила написания spec

https://www.altlinux.org/Особенности_написания_спек_файлов_в_ALT_Linux
https://www.altlinux.org/ALT_Packaging_HOWTO

Здесь про обсуждаемое нет вообще ничего.
Есть на вики про обсуждаемое, но как утверждает сама статья, она протухла.

[ruslandh]

Здесь про обсуждаемое нет вообще ничего.

И поэтому имею право применять ту кодировку, которая мне, как мантейнеру удобна.

Есть на вики про обсуждаемое, но как утверждает сама статья, она протухла.

Какая?
rpm уже лет 10 работал с разными входными локалями. И если поправят, ещё столько-же будет работать.

[Speccyfighter]

Есть на вики про обсуждаемое, но как утверждает сама статья, она протухла.

Какая?

SpecTips/l10n

имею право применять ту кодировку, которая мне, как мантейнеру удобна.

На здоровье. :)
Значит при очередном сломе rpm будем ждать повторения пройденного.

[ruslandh]

Значит при очередном сломе rpm будем ждать повторения пройденного.

Я до него уже не доживу

[ruslandh]

SpecTips/l10n

Вообще-то я не вижу ничего протухшего.  Может её хотел кто-то расширить - не в курсе

[ruslandh]

Значит при очередном сломе rpm будем ждать повторения пройденного.

Даже если так - это Сизиф, тут может всегда что-то сломаться. Это не повод.
Будет 9-й бренч, может тогда решим делать descripction только в utf8, или только в koi8-r (что-бы меcта меньше занимать), а может вообще запретим делать русские decription внутри спека.
Технически это просто - делаешь запрет в скриптах сборочницы и всё.
 А пока сборочница пропускает, никто этим специально занимаьаться не  будет.

[Speccyfighter]

Плюнул и сделал алиас для apt-cache на posix.

[asy]

Но ведь в случае дескрипшнов, собирая новую версию, неужели так трудно просто исправить пару идентификаторов и сохранить спек в utf8?

Обычно используют ту кодировку, в которой работают. Так удобно.

Да не баг это rpm. Баг в описаниях, которые без какой либо надобности понаделаны в нестандартной для целевой системы кодировке.

Нет бага в описаниях, если там указана соответствующая кодировка.

Ну неправда ведь. Спеки такие писались для ALT4, например, в котором utf8 уже была стандартом.

Да ну !? Я вот и сейчас на koi8 бы сидел с удовольствием, если бы пару CUPS+LibreOffice не поломали: https://bugzilla.altlinux.org/29879

[sb]

Есть такое слово: legacy, унаследованный. И я лично и люьрй мейнтейнер будет править локализованные описания в самую последнюю очередь. Потому что времени на это жалко.

Да не баг это rpm. Баг в описаниях, которые без какой либо надобности понаделаны в нестандартной для целевой системы кодировке. Вот скажите, кто вам мешал сохранять спеки в utf8, пусть даже имея в своей системе CP1251? То что оно поддерживалось не оправдание. Вы же знали какая кодировка использовалась в целевой системе?

Так их и не надо править. Надо только сохранять уже открытый спек в utf8. И всё. Дальше все версии этого пакета пойдут правильно. Это одноразовая работа. Если прилепить патч, то каждый раз в каждой следующей версии пакета он будет продолжать болтаться сбоку.

Вот и я говорю, что класть в репу надо по одному правилу определенные спеки. Вы можете хоть на винде сидеть и писать спеки в пресловутой cp1251, но в репе (и в сборочнице) они должны быть в одной кодировке, приведены должны быть к одному виду, чтобы не плодить костыли для rpm в виде поддержки преобразований на лету (здесь могу ошибаться и не совсем понимать механизм преобразований, но в любом разе проще работать с источником, где все предсказуемо, это уменьшает количество кода как минимум на поддержку и, возможно, в лучшую сторону повлияет на коринф опять же по причине уменьшения кода, когда совершенно точно известен шаблон спека и он стандартизирован в плане заполнения). Не думаю, что конвертация это архисложно. К тому же, вариант с сохранением английских дескрипшенов в спеке без локализованных - хороший вариант, опять же, раз маинтейнерам времени жалко на локализацию и не все это делают, предоставьте возможность это делать тем, кто пакетами реально пользуется (и ищет через тот же синаптик или apt-cache, rpm), а не только их собирает/патчит. Сборка же в любом разе на сборочницу завязана и собирается в хэщернице. Не вижу препятствий и противоречий тут.