[devel] Стоит ли резать исходники для сокращения сборочных зависимостей? was: Re: I: gcc4.4-4.4.0-alt4

[Evgeny Sinelnikov]

16 июля 2009 г. 13:01 пользователь Alexander Bokovoy (ab at altlinux.org) написал:
>  2009/7/16 Evgeny Sinelnikov <sin at altlinux.ru>:
>>> Извините, но это какой-то странный аргумент, я не могу его принять при
>>> всем желании. Учитывая, что с некоторых пор исходники документации
>>> существуют в основном дереве. а не раздельно, то "сборка в
>>> самостоятельном пакете" не имеет никакого смысла.
>> Полагаю, что это слишком формальный подход, предполагающий
>> недопустимость разбиения исходников на разные пакеты, если они
>> предоставляются разработчиками в одном тарболе. Из разных позиций
>> следуют разные выводы. Я бы не стал уповать на "разумность"
>> разработчиков, предоставляющих всё в одном большом тарболе. У них есть
>> основания так делать, чтобы не путать пользователя массой необходимых
>> тарболов.
> В данном случае у апстрима были свои причины, чтобы поместить
> исходники документации вместе с остальными и это не забота о
> запутывании/распутывании пользователей. Постарайтесь не сводить все к
> разумности или неразумности коллег.
>

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

>> Тем не менее, мы же разбиваем бинарные пакеты на массу подпакетов,
>> хотя и не все так делают? Это наша вольность, как разбить пакет так,
>> чтобы зависимости были "прямыми". Вторым шагом здесь приходит
>> разбиение на отдельные сущности не только бинарных, но и исходных
>> пакетов. Иначе невозможно "выпрямить" сборочные зависимости.
> Если Вы лично сможете гарантировать, что поставленные Вами разбитые на
> части исходные тексты соответствуют оригиналу от апстрима, который был
> подписан тем или иным образом, то делайте так, как считаете нужным.
> Однако в подавляющем большинстве случаев перепаковка скорее
> запутывает, чем помогает.
>

Вопрос не в путанице, а в сокращении сборочных зависимостей. Много
бинарных деталей от других пакетов тоже, в общем, запутывает. И даже
больше, чем та разбивка исходных пакетов, о которой идёт речь.

Пользователю важно какой пакет стоит поставить от kde, чтобы получить
ту или иную программу, которая у нас запакована отдельно, а, например,
в Fedora в некий монстроподобный пакет. А то, из каких исходных
пакетов собраны эти бинарные пакеты, пользователю всё равно...

Разработчик же, при желании, всегда сможет сделать rpm -qi и всё
увидит. Так что путаницы никакой не будет. Кто будет путаться?

> Если сборка ведется напрямую с использованием системы контроля версий,
> которая хранит информацию о подписанных отметках исторических вех
> апстрима и упаковщика, то в этом случае применимы несколько иные
> подходы и Ваша логическая посылка может быть верна. В случае
> обсуждаемого пакета это не так.
>

Нет. Я вполне могу написать правила для gear, которые будут паковать
только исходники и держать оба пакета со своими спеками в разных
бранчах одного и того же репозитория, в котором будет всё. И
исторические вехи апстрима, и свои изменения... Так что, в данном
случае, всё разрешимо... При желании, конечно...


> К тому же, мы ушли от изначальной темы дискуссии в какие-то непонятные
> дебри, в которых зачем-то возник вопрос необходимости исключения
> сборки документации из сборки основного пакета. Я не понимаю
> осмысленность этого вопроса с самого начала и поэтому не вижу смысла в
> этом развитии дискуссии.
>

Но, тем не менее, вопрос спорен...

-- 
Sin (Sinelnikov Evgeny)