[devel] [jt] о культуре

[Денис Смирнов]

On Mon, Jan 11, 2010 at 12:28:11AM +0300, Afanasov Dmitry wrote:

[skip]

Это все философия, а у нас тут devel@ :)

Я предлагаю вместо общих слов кто там является пакетным менеджером, а кто
некатегоризируемым инструментарием, исходить из use cases, и того решаются
ли они, или нет.

Иначе получается каша в головах.

AD> здесь уже поднимали вопрос о прописывании коммита в rpm, из которого он
AD> вырос. до тех пор, пока данных об этом коммите не будет в самом
AD> репозаитарии (каталог Sisyphus), а не где-то на серверах git.alt,
AD> автоматически выдрать весь gear не получится. максимум, что получится -
AD> получить коммит из /gears. 

Ага. А с ftp взять весь srpm не получится, получится взять только файлик с
расширением .src.rpm. А вдруг у него есть еще какие-то части, которые не
выложены? Например при скачивании по http потеряются права доступа,
которые были выданы этому файлу! А еще там ведь могли быть extended
attributes. Кошмар-кошмар! src.rpm не работает! Всем бояться.

AD> я же веду речь о репозитариях из /people, откуда всё и растёт.

В таком случае я буду утверждать что src.rpm фигня, ибо у меня нет доступа
к личному компьютеру ldv@, из которого растет glibc. Если нет доступа к
glibc, то какой это тогда вообще дистрибутив?

Перевожу: есть git.alt/gears. Там содержится фактически столько же
информации сколько в лежащем в Сизифе файлике src.rpm.

AD> так что нет, не в той же мере. один gear хранит в себе множество srpm, что
AD> поднимает проблему поиска и выбора, где же там нужный нам коммит.

Ой кошмар. А на ftp лежит много-много бранчей, в них много-много файлов. А
еще есть архив предыдущих версий. Жуть! Не разобраться и ничего не найти.

Поясняю -- src.rpm  это всего лишь срез. Точно такой же как tag.

А теперь сформулируй свои красивые слова не в виде сложностей каких-то, а
в виде задачи которую легко решить с помощью src.rpm, и сложно -- с
помощью gear.

AD> я кажется действительно что-то не понимаю. окружение же строится исходя из
AD> зависимостей, почему вы считаете, что наоборот? из-за buildreq? 

Hint: макросы. Т.е. я могу написать в spec:
BuildPreReq: supermacro-package
BuildRequires: %supermacro

И тогда сборочная зависимость у src.rpm будет невычисляема до установки в
chroot supermacro-packages, засовывания туда spec'а и выполнения таки
rpmbuild -bs уже в этом chroot.

Благо gear все это делает за нас. Но да, это приводит к тому что из одного
spec'а теоретически можно получить два разных src.rpm. Хотя бы потому что
макрос может раскрыться вообще в полспека :)

AD> вот, кстати, hasher'у на srpm плевать - он там используется только в рамках
AD> повторного использования кода rpmbuild. будет свой парсер spec, и srpm
AD> для hasher'а будет не нужен.
AD> останется только добавить gears в сам репозитарий и тогда я соглашусь, что
AD> технически srpm не нужен.

Что такое "добавить gears в сам репозитарий"?

AD> да, apt-get всюду работает с базой данных, как rpm так и srpm он дергает
AD> только на этапе установки.
AD> с srpm работает genbasedir, что генерирует эту базу, с которой работает
AD> apt-get. и genbasedir ничерта не знает про gear и его таги.
AD> засим аргумент не принят :)

Итак, src.rpm и тут является лишь промежуточным форматом, самостоятельной
ценности не имеющим.

>> Можно список разных workflow в которых нужен сам srpm, как отдельный
>> имеющий самостоятельную значимость объект, а не как промежуточный формат
>> между gear repo и hasher?
AD> repocop, sisyphus_check, sisyphus.ru, удаление пакета из репозитария
AD> вместе с порожденными binary rpm, вычисление списка бинарных пакетов,
AD> собираемых из данного srpm.

Во-первых это не workflow, а также подзадачи внутри workflow.
Во-вторых во всех их src.rpm нужен на коротком временном интервале, и не
представляет ценности как объект.

-- 
С уважением, Денис

http://freesource.info
----------------------------------------------------------------------------
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.altlinux.org/pipermail/devel/attachments/20100111/b61096f3/attachment.bin>