[devel] bootstrap (was Re: unmets policy)
Денис Смирнов
mithraen at altlinux.ru
Thu Sep 17 18:12:52 UTC 2009
On Thu, Sep 17, 2009 at 11:09:11AM +0400, Vladislav Zavjalov wrote:
VZ> А непонятно. В твоем примере она нужна, чтоб сложить два "прозрачных"
VZ> задания в одно "непрозрачное" и тем самым перешагнуть через недопустимое
VZ> состояние. Но, очевидно, возможность такого сложения убивает всю идею
VZ> "прозрачности" :)
Она и так убита, уже давно.
Привожу интересный пример:
Есть пакеты, скажем mycc1, mycc2. Предположим это такой компилятор с моего
собственного языка программирования, который почти как C ну круче. Они оба
provides mycc.
Теперь я хочу собрать новую крутую версию пакета mycc2.1, который,
разумеется, собирается только компиляторами mycc. В BuildRequires у него
написано: mycc.
Вариант task'а #1:
ssh git.alt task add repo mycc2.1 ...
ssh git.alt task del mycc2
в этой ситуации, очевидно, mycc2.1 будет собран с помощью mycc2.
Вариант task'а #2:
ssh git.alt task del mycc2
ssh git.alt task add repo mycc2.1
в этой ситуации, очевидно, mycc2.1 _должен быть_ собран с помощью mycc1.
При этом как себя поведет сборочница в этой ситуации я не очень понимаю.
В обоих случаях мы получаем абсолютно идентичный результат в A1 по списку
пакетов. Однако реально мы получаем совершенно разные результаты! Например
потому, что mycc2 содержал ошибку в кодогенераторе (из-за которой мы и
затеяли это обновление) и поэтому собранные mycc2.1 в первом случае падать
вместо работы, а во втором -- работать.
Могу повторить еще раз свою мысль -- в настоящий момент наличие снапшотов
репозиториев A0 и A1 не позволяет получить полноценную информацию о том,
каким образом из A0 получили A1. Это технически невозможно без информации
а git.alt/gears и содержимого task'ов.
Кроме того, принципиаьлный вопрос -- а где-то сохраняются _все_ снапшоты
Сизифа после _каждого_ коммита транзакции? Сильно сомневаюсь, таким
образом этой информации в настоящий момент у нас просто нет, если мы не
будем смотреть в task'и.
А если мы смотрим в task'и, то всякие временные репозитории нас не пугают
:)
--
С уважением, Денис
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/20090917/2b4920a7/attachment.bin>
More information about the Devel
mailing list