Alexander Bokovoy пишет: >On Mon, Dec 09, 2002 at 11:50:01PM +0300, AntonFarygin wrote: > > >>>>Тогда у вас есть вероятность в BTE собирать не тем компилятором? >>>> >>>> >>>Нет. У нас ее нет, ибо мы используем ccache с правильными настройками. >>> >>> >>А ccache разваливается в BTE? Или как? >> >> >Не разваливается. Я же написал: "у нас ее (проблемы) нет". > Саш, ты меня не понял. Я спрашивал - как используется ссache в BTE? > > > >>>rsync.altlinux.ru за последние дня 4 испытывал изменения почти только в >>>SRPMS, а >>>все бинарные пакеты не менялись. Например, у меня сейчас в локальном >>>репозитарии от сегодняшнего утра наблюдается целый gnome-panel-2.1.2-alt1 и >>>битый симлинк gnome-panel-2.1.3-alt1. Зеркалирование еще утром делалось с >>>rsync.altlinux.ru. И это не одно такое явление. >>> >>> >>Очень странно. gnome-panel 2.1.3 лежит в Sisyphus со второго декабря (в >>нормальном, а не битом виде). Все нормально и на моей машине, которую я >>вчера зеркалировал с Sisyphus с rsync.altlinux.ru. Никаких проблем не >>возникало с зеркалированием. Да и rsync.altlinux.ru менялся все время >>также нормально (я зеркалирую только бинарные пакеты). >> >> >Мы специально вчера вечером провели ручную синхронизацию с >rsync.altlinux.ru и она оказалась стольже неуспешной по результатам -- >обновлений бинарных пакетов не произошло. Я не знаю, кого здесь обвинять >-- rsync.altlinux.ru, или луну, светившую на трафик по дороге... > Вчера вечером бинарные пакеты _гарантированно_ были. Я специально синхронизировал свой ноутбук с rsync.altlinux.ru - бинарные пакеты есть, все зависимости удовлетворены. Явно проблема или в луне или у вас в rsync. Пришли мне по личной почте rsync -nva --stats --delete-after > > > >>>>Потому для сборки и лучше использовать Master. >>>> >>>> >>>Антон, ты говоришь ерунду. Что это за отношение к Classic как к свалке? >>>Целостность Сизифа обеспечивается или должна обеспечиваться именно по >>>Classic, а не по подмножествам. Иное -- путь к развалу зависимостей, что >>>мы уже и наблюдаем (bootloader-utils, pysol, python21, ряд других) именно >>>из-за ослабления контроля путем самоутешения в подкомпонентах. >>> >>> >>> >>Я бы сказал не так: целостоность Sisyphus должна обеспечиваться как в >>отдельных компонентах, так и в Classic. >> >> >В отдельных компонентах нельзя добиться целостности, за исключением >basesystem. Можно добиться целостности в наборах компонент, поскольку >построены они по принципу матрешек. Так вот, для меня сломанность Contrib >означает сломанность Sisyphus, причем она не замечается apt-get unmet, >зато отлично видна в BTE при использовании механизма сборки или тестовой >установки пакетов. Проблемы с pysol (отсутствие зависимости на tkinterp) >вообще отлавливаются только при использовании -- попытке запуска. Я думаю, >что и эту ситуацию мы будем пытаться в будущем подчинять >автоматизированному тестированию (через использование UML). > Да, BTE вылавливает такие ошибки - я с этим столкнулся буквально сегодня ;) Но у меня все еще тяжелее чем у вас - BTE работает с правами пользователя. ;-) > > > >>То, что битые зависимости - несоменно ошибки, о которых также несомненно >>стоит сообщить в BTS. >> >> >Может стоит поставить PV -- там есть почтовый интерфейс к багам. А то с лазанием >по bugs.altlinux.ru я очень быстро выеду свой 45Мб лимит трафика в неделю >на проксе :( > Может быть. Но лучше что-то тогда интегрированное с BTE и Sisyphus. > > > >>Использовать Master для сборки лучше конечно по другой причине - если >>пакет падает в компоненту Master, то явно лучше собирать с >>использованием этой компоненты, что бы не нарушить ее целостность. >> >> >Я уже говорил, что это деление эфемерное, и приводил в сентябре примеры. >Собственно, благодаря этому и возникло понятие Classic. Деление на Contrib >и Master -- верный путь к ослаблению контроля качества сборки. Вспомните >Contrib в Mandrake. > Для этого и создавался. Промышленный запуск BTE для всего devel@ , в теории, должен повысить качество пакетов, попадаемых в Sisyphus. Я очень надеюсь, что это будет совсем скоро. Rgds, Rider