[devel] firefox-3.0 unmets (Sisyphus-20080709 x86_64 unmets: +54)

[devel] firefox-3.0 unmets (Sisyphus-20080709 x86_64 unmets: +54)

[Alexey Tourbin]

[-- Attachment #1: Type: text/plain, Size: 2757 bytes --]

On Wed, Jul 09, 2008 at 03:23:08AM +0400, QA Team Robot wrote:
> 	54 NEW unmet dependencies detected:
> epiphany#2.22.3-alt1    	/usr/lib64/firefox/libgtkembedmoz.so
> epiphany#2.22.3-alt1    	/usr/lib64/firefox/libxpcom.so
> epiphany#2.22.3-alt1    	/usr/lib64/firefox/libxpcom_core.so
> firefox-calculator#1.1.10-alt1	firefox < 2.1
> firefox-copy_link_name#1.2.4-alt7	firefox < 2.1
> firefox-copyallurls#0.7.1-alt8	firefox < 2.1
> firefox-download_statusbar#0.9.5.2-alt2	firefox < 2.1
> firefox-flashblock#1.5.5-alt1	firefox < 2.1
> firefox-gmail_manager#0.5.4-alt2	firefox < 2.1
> firefox-outliner#0.7-alt7	firefox < 2.1
> firefox-quicknote#0.6.0.3-alt8	firefox < 2.1
> firefox-sessionmanager#0.6.1.6-alt1	firefox < 2.1
> firefox-sessionsaver#0.2.1-alt12	firefox < 2.1
> firefox-simple_calc#0.8-alt15	firefox < 2.1
> firefox-tab_url_copier#1.1.8-alt8	firefox < 2.1
> firefox-tabs_open_relative#0.3-alt3	firefox < 2.1
> firefox-update_notifier#0.1.5.3-alt6	firefox < 2.1
> galeon#2.0.1-alt9       	/usr/lib64/firefox/libgtkembedmoz.so
> galeon#2.0.1-alt9       	/usr/lib64/firefox/libxpcom.so
> galeon#2.0.1-alt9       	/usr/lib64/firefox/libxpcom_core.so
> gnomesword#2.3.1-alt2   	/usr/lib64/xulrunner-1.8.1.10/libgtkembedmoz.so()(64bit)
> gnomesword#2.3.1-alt2   	/usr/lib64/xulrunner-1.8.1.10/libxpcom.so()(64bit)
> gnomesword#2.3.1-alt2   	/usr/lib64/xulrunner-1.8.1.10/libxul.so()(64bit)
> libdevhelp#0.19-alt2.qa1	/usr/lib64/firefox/libgtkembedmoz.so
> libdevhelp#0.19-alt2.qa1	/usr/lib64/firefox/libxpcom.so
[...]
> python-module-Ice#3.2.1-alt2.1	libIce.so.32()(64bit)
> python-module-Ice#3.2.1-alt2.1	libIceUtil.so.32()(64bit)
> python-module-Ice#3.2.1-alt2.1	libSlice.so.32()(64bit)
> python-module-Ice#3.2.1-alt2.1	libice = 3.2.1
> python-module-ice#3.2.1-alt1.1	libice = 3.2.1
> python-module-pygnome-gtkmozembed#2.19.1-alt1.1	/usr/lib64/firefox/libgtkembedmoz.so
> ruby-gtkmozembed#0.16.0-alt7	/usr/lib64/xulrunner-1.8.1.10/libgtkembedmoz.so
> yelp#2.22.1-alt2        	/usr/lib64/firefox/libgtkembedmoz.so
> yelp#2.22.1-alt2        	/usr/lib64/firefox/libxpcom.so
> yelp#2.22.1-alt2        	/usr/lib64/firefox/libxpcom_core.so

Сейчас нельзя одновременно установить firefox и gnumeric, из-за того,
что gnumeric требует yelp.

Вообще, если бы все проверки выполнялись честно, то сборочная система
никогда бы не пропустила такой транзакции.

С другой стороны, транзакция слишком толстая; здесь вовлечено не только
много пакетов, но и много maintainer'ов, так что исправить все пакеты за
один раз может быть довольно проблемно.

Интересно, как лучше всего поступать в подобных ситуациях (с точки
зрения логики проверок в сборочной системе и с точки зрения организации
совместного "перехода").

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: [devel] firefox-3.0 unmets (Sisyphus-20080709 x86_64 unmets: +54)

[Alexey Gladkov]

Alexey Tourbin wrote:
> С другой стороны, транзакция слишком толстая; здесь вовлечено не только
> много пакетов, но и много maintainer'ов, так что исправить все пакеты за
> один раз может быть довольно проблемно.

Более того, простой пересборкой эти расширения не вылечатся. Даже если 
они будут устанавливаться с систему rpm, они не будут работать в ff3. 
Большинство из этих расширений нужно обновлять.

-- 
Rgrds, legion

Re: [devel] firefox-3.0 unmets (Sisyphus-20080709 x86_64 unmets: +54)

[Mikhail Gusarov]

[-- Attachment #1: Type: text/plain, Size: 711 bytes --]

Twas brillig at 04:02:04 09.07.2008 UTC+04 when at@altlinux.ru did gyre and gimble:

 AT> Интересно, как лучше всего поступать в подобных ситуациях (с точки
 AT> зрения логики проверок в сборочной системе и с точки зрения
 AT> организации совместного "перехода").

Расскажу, как сделано в Debian: там такие пакеты варятся в unstable до
тех пор, пока все вместе не станут устанавливаемыми, и тогда одной
транзакцией перемещаются в testing.

-- 

[-- Attachment #2: Type: application/pgp-signature, Size: 188 bytes --]

Re: [devel] firefox-3.0 unmets (Sisyphus-20080709 x86_64 unmets: +54)

[Ildar Mulyukov]

On 09.07.2008 06:02:04, Alexey Tourbin wrote:
> Интересно, как лучше всего поступать в подобных ситуациях (с точки
> зрения логики проверок в сборочной системе и с точки зрения  
> организации
> совместного "перехода").

Как я полагаю, подготовить мэйнтейнеров заранее на той сборке, которая  
в people. Надеюсь, именно так и произошло (незаметно для окружающих,  
приватом)
-- 
Ildar  Mulyukov,  free SW designer/programmer/packager
=========================================
email: ildar@altlinux.ru
Jabber: ildar@jabber.ru
ICQ: 4334029
ALT Linux Sisyphus http://www.sisyphus.ru
=========================================

Re: [devel] firefox-3.0 unmets (Sisyphus-20080709 x86_64 unmets: +54)

[Alexey Gladkov]

Mikhail Gusarov wrote:
> Расскажу, как сделано в Debian: там такие пакеты варятся в unstable до
> тех пор, пока все вместе не станут устанавливаемыми, и тогда одной
> транзакцией перемещаются в testing.

Как я и писал в этот же список, я выкладывал (и анонсировал) в people 
промежуточные сборки, чтобы другие мантейнеры смогли подготовиться.

-- 
Rgrds, legion

Re: [devel] firefox-3.0 unmets (Sisyphus-20080709 x86_64 unmets: +54)

[Alexey Gladkov]

Alexey Gladkov wrote:
> Alexey Tourbin wrote:
>> С другой стороны, транзакция слишком толстая; здесь вовлечено не только
>> много пакетов, но и много maintainer'ов, так что исправить все пакеты за
>> один раз может быть довольно проблемно.
> 
> Более того, простой пересборкой эти расширения не вылечатся. Даже если 
> они будут устанавливаться с систему rpm, они не будут работать в ff3. 
> Большинство из этих расширений нужно обновлять.

Более того, некоторые расширения в такой транзакции должны быть 
удалены из репозитория. Например в данном случае это 
firefox-russian_hot_keys_bugfix. Я не знаю как это сделать атомарно. 
Перенос в obsoletes не может быть автоматическим по чужому запросу.

-- 
Rgrds, legion

Re: [devel] firefox-3.0 unmets (Sisyphus-20080709 x86_64 unmets: +54)

[Konstantin A. Lepikhov]

Hi Ildar!

Wednesday 09, at 12:22:06 PM you wrote:

> On 09.07.2008 06:02:04, Alexey Tourbin wrote:
> > Интересно, как лучше всего поступать в подобных ситуациях (с точки
> > зрения логики проверок в сборочной системе и с точки зрения  
> > организации
> > совместного "перехода").
> 
> Как я полагаю, подготовить мэйнтейнеров заранее на той сборке, которая  
> в people. Надеюсь, именно так и произошло (незаметно для окружающих,  
> приватом)
автомагически :)

-- 
WBR et al.

Re: [devel] firefox-3.0 unmets (Sisyphus-20080709 x86_64 unmets: +54)

[Michael Shigorin]

On Wed, Jul 09, 2008 at 04:02:04AM +0400, Alexey Tourbin wrote:
> Интересно, как лучше всего поступать в подобных ситуациях
> (с точки зрения логики проверок в сборочной системе и с точки
> зрения организации совместного "перехода").

http://lists.altlinux.org/pipermail/devel/2008-June/075897.html
http://lists.altlinux.org/pipermail/devel/2006-June/046438.html
(и рядом по первому треду)?

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

Re: [devel] firefox-3.0 unmets (Sisyphus-20080709 x86_64 unmets: +54)

[Vitaly Lipatov]

On 9 июля 2008, Alexey Gladkov wrote:
> Mikhail Gusarov wrote:
> > Расскажу, как сделано в Debian: там такие пакеты варятся в
> > unstable до тех пор, пока все вместе не станут
> > устанавливаемыми, и тогда одной транзакцией перемещаются в
> > testing.
>
> Как я и писал в этот же список, я выкладывал (и анонсировал) в
> people промежуточные сборки, чтобы другие мантейнеры смогли
> подготовиться.
Это неправильно, потому что несистемно. Один где-то выкладывает, 
другой где-то выкладывает...
так что идея некоего чистилища, где вызывающие unmets пакеты 
варятся и ждут пакетов, устраняющих анметы, мне представляется 
опять здравой.
Суть в постоянном адресе этого временного репозитория, постоянно 
содержащего только проблемные в зависимостях пакеты.
Введение буферного репозитория для таких пакетов снизило бы 
количество проблем с установкой из Сизифа и увеличила бы 
наглядность проблем.


-- 
С уважением,
Виталий Липатов
Санкт-Петербург
GNU! ALT Linux Team! WINE! LaTeX! LyX! http://freesource.info

Re: [devel] firefox-3.0 unmets

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 1102 bytes --]

On Wed, Jul 09, 2008 at 04:02:04AM +0400, Alexey Tourbin wrote:
> On Wed, Jul 09, 2008 at 03:23:08AM +0400, QA Team Robot wrote:
> > 	54 NEW unmet dependencies detected:
> > epiphany#2.22.3-alt1    	/usr/lib64/firefox/libgtkembedmoz.so
[...]
> > yelp#2.22.1-alt2        	/usr/lib64/firefox/libxpcom_core.so
> 
> Сейчас нельзя одновременно установить firefox и gnumeric, из-за того,
> что gnumeric требует yelp.
> 
> Вообще, если бы все проверки выполнялись честно, то сборочная система
> никогда бы не пропустила такой транзакции.
> 
> С другой стороны, транзакция слишком толстая; здесь вовлечено не только
> много пакетов, но и много maintainer'ов, так что исправить все пакеты за
> один раз может быть довольно проблемно.
> 
> Интересно, как лучше всего поступать в подобных ситуациях (с точки
> зрения логики проверок в сборочной системе и с точки зрения организации
> совместного "перехода").

Идея: индексировать и публиковать незавершённую транзакцию, чтобы
упростить (потенциальным) участникам её завершение.

Технически ничего сложного в этом я не вижу.


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: [devel] firefox-3.0 unmets

[Michael Shigorin]

On Thu, Jul 10, 2008 at 02:01:52AM +0400, Dmitry V. Levin wrote:
> Идея: индексировать и публиковать незавершённую транзакцию,
> чтобы упростить (потенциальным) участникам её завершение.
> Технически ничего сложного в этом я не вижу.

Ну так сколько лет уже про sandman pockets пытаюсь донести :-)

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

Re: [devel] firefox-3.0 unmets (Sisyphus-20080709 x86_64 unmets: +54)

[Alexey Tourbin]

[-- Attachment #1: Type: text/plain, Size: 1401 bytes --]

On Wed, Jul 09, 2008 at 01:20:32PM +0700, Mikhail Gusarov wrote:
> Twas brillig at 04:02:04 09.07.2008 UTC+04 when at@altlinux.ru did gyre and gimble:
> 
>  AT> Интересно, как лучше всего поступать в подобных ситуациях (с точки
>  AT> зрения логики проверок в сборочной системе и с точки зрения
>  AT> организации совместного "перехода").
> 
> Расскажу, как сделано в Debian: там такие пакеты варятся в unstable до
> тех пор, пока все вместе не станут устанавливаемыми, и тогда одной
> транзакцией перемещаются в testing.

Что такое "варятся"?  Дело в том, что собранные пакеты должны быть
жестко привязаны к содержимому чрута, в котором они собрались.

B(S,C)->P
B - функция сборки, релизуемая хешером,
S - исходный код (src.rpm пакет),
C - chroot (базовая сборочная среда + BuildRequires, установленные в чрут),
P - собранные пакеты на выходе.

"Жестко привязаны" означает, что мы отслеживаем взаимное влияние между
пакетами.  Если содержимое чрута изменилось, то для пакета S требуется
либо тестовая пересборка (если он уже находится в репозитарии), либо
полная пересборка (если он ещё только "варится" на подходах к
репозитарию).

В этом смысле нельзя "варить" нечто неопределённое, а "пакет" -- это
определённо тройка <S,C,P>.  Пакеты не могут просто лежать и ждать,
пока они все вместе станут устанавливаемыми -- все переходные состояния
должны быть зафиксированы.

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: [devel] firefox-3.0 unmets (Sisyphus-20080709 x86_64 unmets: +54)

[Mikhail Gusarov]

[-- Attachment #1: Type: text/plain, Size: 801 bytes --]

Twas brillig at 07:04:11 10.07.2008 UTC+04 when at@altlinux.ru did gyre and gimble:

 >> Расскажу, как сделано в Debian: там такие пакеты варятся в unstable до
 >> тех пор, пока все вместе не станут устанавливаемыми, и тогда одной
 >> транзакцией перемещаются в testing.

 AT> Что такое "варятся"? Дело в том, что собранные пакеты должны быть
 AT> жестко привязаны к содержимому чрута, в котором они собрались.

Конечно, в Debian это не отслеживается. Я и не говорю, что можно "как
есть" применять.

-- 

[-- Attachment #2: Type: application/pgp-signature, Size: 188 bytes --]

Re: [devel] firefox-3.0 unmets (Sisyphus-20080709 x86_64 unmets: +54)

[Alexey Tourbin]

[-- Attachment #1: Type: text/plain, Size: 1080 bytes --]

On Thu, Jul 10, 2008 at 12:17:02PM +0700, Mikhail Gusarov wrote:
> >> Расскажу, как сделано в Debian: там такие пакеты варятся в unstable до
> >> тех пор, пока все вместе не станут устанавливаемыми, и тогда одной
> >> транзакцией перемещаются в testing.
>
> AT> Что такое "варятся"? Дело в том, что собранные пакеты должны быть
> AT> жестко привязаны к содержимому чрута, в котором они собрались.
> 
> Конечно, в Debian это не отслеживается. Я и не говорю, что можно "как
> есть" применять.

Это наводит на как бы философские соображения, что такое "пакет"
или "пакеты".  Возможны две крайние точки зрения:

1) Атомистическая.
Пакет это <S,P>, т.е. исходный код и собранные пакеты.
Здесь не учитывается влияние сборочной среды.

2) Холистическая.
Пакет это <S,C,P>, где C -- сборочная среда.
Здесь в понятие пакета влючено множестов других пакетов С, которые
были в чруте при сборке S и повлияли на содержимое собранных пакетов P.

Чтобы избежать философских крайностей, нужно, по-видимому, как-то
отслеживать влияние сборочной среды на собранные пакеты.

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: [devel] firefox-3.0 unmets (Sisyphus-20080709 x86_64 unmets: +54)

[Dmitriy M. Maslennikov]

10.07.08, Alexey Tourbin<at@altlinux.ru> написал(а):
> Это наводит на как бы философские соображения, что такое "пакет"
>  или "пакеты".  Возможны две крайние точки зрения:
>
>  1) Атомистическая.
>  Пакет это <S,P>, т.е. исходный код и собранные пакеты.
>  Здесь не учитывается влияние сборочной среды.
>
>  2) Холистическая.
>  Пакет это <S,C,P>, где C -- сборочная среда.
>  Здесь в понятие пакета влючено множестов других пакетов С, которые
>  были в чруте при сборке S и повлияли на содержимое собранных пакетов P.
>
>  Чтобы избежать философских крайностей, нужно, по-видимому, как-то
>  отслеживать влияние сборочной среды на собранные пакеты.
Может проще считать, что пакет -- это его исходники (вместе со
спеком)? На него влияют исходники всех его зависимостей. "Варятся" --
это означает, что исходники правятся до приемлимого состояния в
unstable. Потом пакет перекладывается со всеми зависимостями в
testing. Так как его исходники были уже вылизаны, то должен получиться
правильный результат в testing. Если это не так, то возвращаемся в
unstable, если же все ок, то перекладываем пакеты в stable. Я вижу
проблему Alt в том, что testing и unstable объеденены в sisyphus'е. А
вместо одного stable -- куча бранчей, причем последний оказывается
немного unstable, а более старые почти не поддерживаются.
Под перекладыванием я имел в виду перекладывание пакетов, как
исходников. Пересобирать же надо уметь все пакеты, которые
затрагиваются новыми. При этом можно будет обновлять и важные пакеты,
от которых зависят многие другие, и не иметь проблем с безнадежным
устареванием бранчей.

-- 
Dmitriy M. Maslennikov
rlz@etersoft.ru
rlz@altlinux.org
maslennikovdm@gmail.com
master@armory.ru

Re: [devel] firefox-3.0 unmets (Sisyphus-20080709 x86_64 unmets: +54)

[Alexey Tourbin]

[-- Attachment #1: Type: text/plain, Size: 1612 bytes --]

On Thu, Jul 10, 2008 at 11:30:41AM +0400, Dmitriy M. Maslennikov wrote:
> 10.07.08, Alexey Tourbin<at@altlinux.ru> написал(а):
> > Это наводит на как бы философские соображения, что такое "пакет"
> >  или "пакеты".  Возможны две крайние точки зрения:
> >
> >  1) Атомистическая.
> >  Пакет это <S,P>, т.е. исходный код и собранные пакеты.
> >  Здесь не учитывается влияние сборочной среды.
> >
> >  2) Холистическая.
> >  Пакет это <S,C,P>, где C -- сборочная среда.
> >  Здесь в понятие пакета влючено множестов других пакетов С, которые
> >  были в чруте при сборке S и повлияли на содержимое собранных пакетов P.
> >
> >  Чтобы избежать философских крайностей, нужно, по-видимому, как-то
> >  отслеживать влияние сборочной среды на собранные пакеты.
> Может проще считать, что пакет -- это его исходники (вместе со
> спеком)? На него влияют исходники всех его зависимостей. "Варятся" --
> это означает, что исходники правятся до приемлимого состояния в

Вы хорошо осознали формулу B(S,C)->P ?

Я утверждал, что пакет существует лишь как тройка <S,C,P>.
То есть, пакет существует лишь как артефакт функции сборки, и он
жестко привязан к той сборочной среде, в которой он собрался.
В другой сборочной среде C1 тот же самый пакет <S,C,P> просто не
существует, нету такого понятия (это крайний холистический взгляд
на пакеты).

Далее, править исходники нельзя, потому что P это образ S.
То есть, фиксируя исходники S и сборочную среду C, мы получаем
понятие пакета <S,C,P>.  Всё остальное это не пакеты, а так вообще
какие-то файлы левые в каталогах лежат, которые нужно удалить.

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: [devel] firefox-3.0 unmets (Sisyphus-20080709 x86_64 unmets: +54)

[Dmitriy M. Maslennikov]

10.07.08, Alexey Tourbin<at@altlinux.ru> написал(а):
> Вы хорошо осознали формулу B(S,C)->P ?
Хорошо, и что?

>  Я утверждал, что пакет существует лишь как тройка <S,C,P>.
А я утверждал, что удобнее когда не так.

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

>  В другой сборочной среде C1 тот же самый пакет <S,C,P> просто не
>  существует, нету такого понятия (это крайний холистический взгляд
>  на пакеты).
Если исходники всех зависимостей и самого пакета одни и те же, то
бинарный результат вполне предсказуем.

>  Далее, править исходники нельзя, потому что P это образ S.
>  То есть, фиксируя исходники S и сборочную среду C, мы получаем
>  понятие пакета <S,C,P>.  Всё остальное это не пакеты, а так вообще
>  какие-то файлы левые в каталогах лежат, которые нужно удалить.
Вот в том то и проблема, что сборочную среду как-то стремно
фиксировать. Потом ничего менять нельзя. Так вот и бранч не обновишь
из-за того, что там у всех пакетов в сборочной среде был какой-то там
пакет, который всем нужен, вот его и не обновить никак...
Может проще будет тогда представить с другой стороны: вот есть Gentoo.
Там исходники какбы начало всего. Вот выложили вы исходники в testing
и пересобрали мир. Если с исходниками все в порядке, то testing выйдет
аккуратным без анметов и прочих неприятностей. Можно его тогда в
stable перекладывать, если нет, то обратно в unstable, где исходники
править до приемлимого состояния, там они и не пересобираются иногда и
ждут правок от зависимостей и прочее.
То есть, пакет должен быть функцией от исходников - своих и зависимостей.
Тругое дело, что кроме всего прочего средств для пересборки сизифа нет
и testing'а тоже нет.

-- 
Dmitriy M. Maslennikov
rlz@etersoft.ru
rlz@altlinux.org
maslennikovdm@gmail.com
master@armory.ru

Re: [devel] firefox-3.0 unmets (Sisyphus-20080709 x86_64 unmets: +54)

[Alexey Tourbin]

[-- Attachment #1: Type: text/plain, Size: 4550 bytes --]

On Thu, Jul 10, 2008 at 12:07:53PM +0400, Dmitriy M. Maslennikov wrote:
> 10.07.08, Alexey Tourbin<at@altlinux.ru> написал(а):
> > Вы хорошо осознали формулу B(S,C)->P ?
> Хорошо, и что?

Хорошо. :)

> >  Я утверждал, что пакет существует лишь как тройка <S,C,P>.
> А я утверждал, что удобнее когда не так.

"Не так" не бывает, потому что программа hasher реализует функцию
B(S,C)->P, и эта функция ложится в основу модели данных.

То есть, по-Вашему, удобнее не так, как есть на самом деле.
Но есть так, как есть на самом деле.

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

Нет, "исходники всех зависимостей" тоже были пропущены через функцию B;
и даже сам порядок, в котором они были пропущены, может дать неидентичный
результат сборочной среды C.

Значит, исходники "слишком исходны", чтобы идентифицировать что-либо
в конечном счете.  Предыдующая история сборки этих исходников продолжает
влиять слишком долго.

> >  В другой сборочной среде C1 тот же самый пакет <S,C,P> просто не
> >  существует, нету такого понятия (это крайний холистический взгляд
> >  на пакеты).
> Если исходники всех зависимостей и самого пакета одни и те же, то
> бинарный результат вполне предсказуем.

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

Но мы имеем hahser, который не пересобирает все исходники всех
зависимостей по несколько раз, прежде чем собрать что-то новое.

Значит, мы имеем достаточно сложную модель данных: "постепенные
промежуточные переходы" из одного состояния в другое состояние.
Последовательность постепенных переходов "схлопнуть" нельзя.

> >  Далее, править исходники нельзя, потому что P это образ S.
> >  То есть, фиксируя исходники S и сборочную среду C, мы получаем
> >  понятие пакета <S,C,P>.  Всё остальное это не пакеты, а так вообще
> >  какие-то файлы левые в каталогах лежат, которые нужно удалить.
> Вот в том то и проблема, что сборочную среду как-то стремно
> фиксировать. Потом ничего менять нельзя. Так вот и бранч не обновишь
> из-за того, что там у всех пакетов в сборочной среде был какой-то там
> пакет, который всем нужен, вот его и не обновить никак...

Как установить идентичность пакета?  Что такое пакет?
Пакет, это что, %name-%version-%release.src.rpm?
Но нас интересуют не столькко исходники, сколько результат их сборки.
Мой ответ: пакет -- это, строго говоря, <S,C,P>.

(Как быть с обновлением одного из пакетов в сборочной среде -- это другой
вопрос.  По крайне мере, нужно убедиться, что все пакеты в этой новой
сборочной среде поддаются пересборке, и что у пересобранных пакетов не
меняются зависимости.  Тогда идентичность ранее собранных пакетов в
какой-то степени обеспечивается.)

> Может проще будет тогда представить с другой стороны: вот есть Gentoo.
> Там исходники какбы начало всего. Вот выложили вы исходники в testing
> и пересобрали мир. Если с исходниками все в порядке, то testing выйдет
> аккуратным без анметов и прочих неприятностей. Можно его тогда в

Вы описываете bootstrap -- типа, "всё пересобрать с нуля" из исходников.
На самом деле это слабая форма bootstrap'а.  Для сильного bootstrap'а
нужно всё пересобрать ещё раз (с полным замещением) и убедиться, что
результат получился идентичный.

Что касается Сизифа, то полная пересборка практически нереальна, и нужно
выдумывать модель данных с "постепенными переходами" и фиксацией
промежуточных изменений.

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

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

> То есть, пакет должен быть функцией от исходников - своих и зависимостей.
> Тругое дело, что кроме всего прочего средств для пересборки сизифа нет
> и testing'а тоже нет.

Вы оптимистично настроены насчёт "исходников зависимостей".  А ведь это
рекурсивный процесс.  "Исходники зависимостей" нужно для начала собрать.
А чтобы их для начала собрать, нужно сначала собрать ты-ты-ты и т.д.

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: [devel] firefox-3.0 unmets (Sisyphus-20080709 x86_64 unmets: +54)

[Dmitriy M. Maslennikov]

10.07.08, Alexey Tourbin<at@altlinux.ru> написал(а):
...

Вы, конечно правы, но я смотрю скорее не на то, что есть, а на то, в
каком направлении нужно идти. Так вот я и говорю, что текущая ситуация
приводит к тому, что совершенно непроверенные пакеты лежат вместе с
тестирующимися в сизифе, обновить бранчи -- целая наука (не
построенная до конца), пересборка сизифа -- задача достойная доклада
на конференции. При том, что могло быть и проще, если бы был механизм
пересборки всего затронутого и три репозитария. Gentoo упомянул не
случайно, там механизм пересборки всего (bootstrap) очень хорошо
отточен и выполняется всеми пользователями на своих домашних
компьютерах. В идеале пересобираться должны только затрагиваемые
пакеты. И только для некоторые необходимо пересобирать дважды. Это не
значит, что я за source-based дистрибутивы. Я просто считаю, что
пакетному дистрибутиву можно наводить порядок в своих пакетах похожим
методом.

Кстати, если так будет проще, то пакет это не
%name-%version-%release.src.rpm, а
%name-%version-%release.%build.%arch.rpm, где %build -- номер сборки.

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

-- 
Dmitriy M. Maslennikov
rlz@etersoft.ru
rlz@altlinux.org
maslennikovdm@gmail.com
master@armory.ru

Re: [devel] firefox-3.0 unmets (Sisyphus-20080709 x86_64 unmets: +54)

[Alexey Tourbin]

[-- Attachment #1: Type: text/plain, Size: 1617 bytes --]

On Thu, Jul 10, 2008 at 01:09:06PM +0400, Dmitriy M. Maslennikov wrote:
> Вы, конечно правы, но я смотрю скорее не на то, что есть, а на то, в
> каком направлении нужно идти. Так вот я и говорю, что текущая ситуация
> приводит к тому, что совершенно непроверенные пакеты лежат вместе с
> тестирующимися в сизифе, обновить бранчи -- целая наука (не
> построенная до конца), пересборка сизифа -- задача достойная доклада
> на конференции. При том, что могло быть и проще, если бы был механизм

Вы тоже правы.  Нужен достаточно умный механизм обслуживания совместной
разработки по части сборки пакетов.  Я над этим думал некоторое время,
и изложил некоторые свои соображнеия здесь:
ftp://ftp.altlinux.org/pub/people/at/protva-2008.pdf

> пересборки всего затронутого и три репозитария. Gentoo упомянул не
> случайно, там механизм пересборки всего (bootstrap) очень хорошо
> отточен и выполняется всеми пользователями на своих домашних

Мы не может полностью пересобрать Сизиф (с замещением пакетов).
Не можем не в смысле физической возможности, а в том смысле, что в мое
представление о технологии разработки никак не вписывается полная
(замещающая) пересборка репозитория "на всякий случай".

> компьютерах. В идеале пересобираться должны только затрагиваемые
> пакеты. И только для некоторые необходимо пересобирать дважды. Это не
> значит, что я за source-based дистрибутивы. Я просто считаю, что
> пакетному дистрибутиву можно наводить порядок в своих пакетах похожим
> методом.

Возможно отслеживание "постепенных переходов" и промежуточного изменения
зависимостей.  Всё это возможно.

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]