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 ----------------------------------------------------------------------------