[devel] поддержка пакетов в git

[devel] поддержка пакетов в git

[Dmitry Afanasov]

24.09.08, Konstantin A. Lepikhov<lakostis@altlinux.org> написал(а):
> Предлагаю сначала разобраться в сути вопроса, т.е. не _у кого changelog
>  длинее_, а для чего пакет нужен.
великолепная формулировка! именно с этого вопроса тред и начался.

другое дело, что сейчас он перешел на организацию работы в git, по
моей инициативе в том числе, без привязки к kernel-source.

> Текущее обсуждение мне кажется словоблудием, поскольку ни одного
> обоснованного высказывания не прозвучало, не говоря уже о рабочих
> предложениях.
за сим я изменяю subject :)
-- 
С уважением
Афанасов Дмитрий

Re: [devel] поддержка пакетов в git

[Dmitriy M. Maslennikov]

24 сентября 2008 г. 14:50 пользователь Dmitry Afanasov
<afanasovdmitry@gmail.com> написал:
> великолепная формулировка! именно с этого вопроса тред и начался.
>
> другое дело, что сейчас он перешел на организацию работы в git, по
> моей инициативе в том числе, без привязки к kernel-source.
Раз уж пошла такая пьянка, то я заявляю, что по моему мнению пакеты
собирать прямо из git -- есть очень хорошо. SRPM -- не нужны вообще.
RPM -- просто ужасен. Changelog в пакете не нужен вообще.

Последние два пункта считаю, что необходимо пояснить.

RPM справляется со своей работой, только принаполнении единственного
репозитария. Но на практике их много и пакеты в них пересекаются, да и
я люблю собирать пакеты для себя, потому что изредка что-то в Сизифе
не устраивает. Как в таком случае вести changelog? Поднимать релиз?

Я так понимаю, что по сути пакет -- это набор файлов со скриптами
установки/удаления. Репозитарий набор пакетов, причем удобный для
обновления. Changelog -- это история изменения пакета В РЕПОЗИТАРИИ, а
не пакета вообще. Но почему-то его запихнули в пакет. Для чего? Почему
changelog указывается перед сборкой пакета, а не в момент помещения
его в репозитарий?

Кроме того, маразм требовать, чтобы из apt приезжали только новые
пакеты, в смысле версии самого пакета. Ну почему, если выложили новую
версию openoffice на тестирование в Сизиф, то при серьездных проблемах
необходимо обязательно ПЕРЕСОБИРАТЬ старую, которая и без того уже
собрана? (так еще и со сменой serial!!!) Почему просто не выложить
старые бинарные пакеты? Раз их решили выложить поверх старых, то на
это есть причины, которые и раскрываться в changelog'е репозитария,
где случилась коллизия. Ну не перед сборкой же это указывать? Ну это
же маразм! Все-таки changelog описывает не изменения в spec'е (они
пользователям нафик не нужны и пусть отслеживаются системой контроля
версий) или исходниках, а изменения самого пакета, по сравнению с
предыдущим. При этом о предыдущем имеет смысл говорить только в
контексте репозитария.

Самое главное, к чему, все это приводит -- это невозможность создавать
альтернативные сборки. А ведь очень хочется... И не только мне! Совсем
недавно была ругань по поводу альтернативного пакета залитого в
Daedalus. И всем известны альтернативные ядра... Да много всего. И
никаких проблем бы не возникало, если бы каждый мог создать свою
сборку в свой репозитарий, а все желающие могли бы подключить его
репозитарий с большим приоритетом, чем официальный. И число людей
сделавших такой выбор было бы хорошим аргументом в пользу переноса
именно его пакетов в официальный репозиторий. И не надо их при этом
пересобирать, ибо ну нечего там пересобирать... Его надо только
проверить на совместимость содержимого с библиотеками, но это и так
будет видно как unmet'ы. Возможно надо будет поменять скрипты
установки... И что ради этого пересобирать тяжелый пакет?

Но сейчас это не возможно, а одни только лишние пересборки (версию,
забыл поднять, changelog забыл добавить и т. п.) и огромные проблемы
создания альтернативного репозитария (разве что называть пакеты другим
именем, иначе путаются версии, релизы, changelog'и).

Вот. Накипело.

P. S. Точно не помню кто, но кто-то из Альтов говорил, что rpm -- это
единственная программа, к которой у него нет притензий. Так вот у меня
rpm и apt -- программы, к которым у меня больше всего притензий,
поскольку они системообразующи и косяки в них распространяются на всю
систему.

P. P. S. К сожалению, на поворот к лучшему даже не надеюсь.

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

Re: [devel] поддержка пакетов в git

[Dmitry Afanasov]

24.09.08, Dmitriy M. Maslennikov<maslennikovdm@gmail.com> написал(а):
> Раз уж пошла такая пьянка, то я заявляю, что по моему мнению пакеты
>  собирать прямо из git -- есть очень хорошо. SRPM -- не нужны вообще.
>  RPM -- просто ужасен. Changelog в пакете не нужен вообще.
gear-build world
и всё!
:)

мнение интересное. году в 2001м меня долго обрабатывали на debian
именно из-за странного поведения связки и apt'а. debain'щики на альт
не хотели идти именно поэтому, хотя в той сети альт был не только у
меня.

к сожалению как изменить сам репозитарий я даже не представляю. apt на
gear настравливать? gear учить хранить бинарники? или как в gentoo
устанавливать из исходников - тот самый gear world? или совсем
радикальный метод - на *.deb перейти? сам знаю, последнее из мира
абсурда :)

черт его знает. на данный момент все идет к замене incoming и srpm
хранилища на работу с gear. и раз идет такая привязка к git, такую
замену провести необходимо, пока мантейнеры не порвались между
желаемым действительным :)
-- 
С уважением
Афанасов Дмитрий

Re: [devel] поддержка пакетов в git

[Dmitriy M. Maslennikov]

24 сентября 2008 г. 16:06 пользователь Dmitry Afanasov
<afanasovdmitry@gmail.com> написал:
> gear-build world
> и всё!
> :)
>
> мнение интересное. году в 2001м меня долго обрабатывали на debian
> именно из-за странного поведения связки и apt'а. debain'щики на альт
> не хотели идти именно поэтому, хотя в той сети альт был не только у
> меня.
>
> к сожалению как изменить сам репозитарий я даже не представляю. apt на
> gear настравливать? gear учить хранить бинарники? или как в gentoo
> устанавливать из исходников - тот самый gear world? или совсем
> радикальный метод - на *.deb перейти? сам знаю, последнее из мира
> абсурда :)
>
> черт его знает. на данный момент все идет к замене incoming и srpm
> хранилища на работу с gear. и раз идет такая привязка к git, такую
> замену провести необходимо, пока мантейнеры не порвались между
> желаемым действительным :)
Я бы научил apt...
1. возможности добавить пакет в репозитарий (ему присваивается apt-версия 1).
2. возможности обновить пакет в репозитарии, указав причину замены
(apt-версия пакета поднимается, причина запоминается в changelog).
3. возможность на клиенте указывать приоритеты репозитариев в
source.list, при этом обновляется и устанавливается только пакет из
репозитария с большим приоритетом, а репозитарии с меньшим
рассматриваются только в случае, если в более приоритетных
запрашиваемый пакет не существует.

Я бы научил gear писать идентификатор коммита и git-репозиторий в спек
(вместо rpm-changelog'а) при сборке и отдельно указавать, что тот был
временным (--commit)

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

Я бы сделал возможность перекладывать пакеты из тестовых репозиториев
в официальный с указанием причины замены предыдущего.

Это если навскидку.

Эх, мечты-мечты...

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

Re: [devel] поддержка пакетов в git

[Damir Shayhutdinov]

> мнение интересное. году в 2001м меня долго обрабатывали на debian
> именно из-за странного поведения связки и apt'а. debain'щики на альт
> не хотели идти именно поэтому, хотя в той сети альт был не только у
> меня.
Связки и apt-а?
Ну что дебианщики умеют обрабатывать - мы все знаем. Альтовцы в этом
тоже не последние люди. Приходите к нам - мы вас тоже обработаем
(почти цитата по Путину).

> к сожалению как изменить сам репозитарий я даже не представляю. apt на
> gear настравливать? gear учить хранить бинарники? или как в gentoo
> устанавливать из исходников - тот самый gear world? или совсем
> радикальный метод - на *.deb перейти? сам знаю, последнее из мира
> абсурда :)
Ага, а когда кончился бензин - надо менять колеса. Логика замечательная.
Не надо ничего менять. То, что предлагается сейчас сделать в Альте -
это на мой взгляд наиболее правильный вариант. git->(временный
srpm)->rpm. Если хочется генту - ставьте генту.

> черт его знает. на данный момент все идет к замене incoming и srpm
> хранилища на работу с gear. и раз идет такая привязка к git, такую
> замену провести необходимо, пока мантейнеры не порвались между
> желаемым действительным :)
Насколько я понимаю, srpm никуда не девается, он просто становится
временным "транспортом" между git и rpmbuild.
Аналогия тут как с кодом на С и результатом работы препроцессора.
Компилятор С работает не с исходным кодом на С, а с результатом
обработки этого исходного кода препроцессором. Результат этот можно
увидеть запустив gcc -E. Вы его обычно не видите, а он - есть! Так
будет и с srpm. Аналог gcc -E  для .src.rpm - это gear --rpmbuild rpm
-bs.

Re: [devel] поддержка пакетов в git

[Damir Shayhutdinov]

> Последние два пункта считаю, что необходимо пояснить.
Правильно, потому что эти два пункта - полнейшая ерунда.


> RPM справляется со своей работой, только принаполнении единственного
> репозитария. Но на практике их много и пакеты в них пересекаются, да и
> я люблю собирать пакеты для себя, потому что изредка что-то в Сизифе
> не устраивает. Как в таком случае вести changelog? Поднимать релиз?
Да. А вообще если что-то не устраивает - можно попробовать
договориться с мантейнером.

Приведите что-ли пример какой-нить, а то голословно получается.


> Я так понимаю, что по сути пакет -- это набор файлов со скриптами
> установки/удаления. Репозитарий набор пакетов, причем удобный для
> обновления. Changelog -- это история изменения пакета В РЕПОЗИТАРИИ, а
> не пакета вообще.
Вот это глупость. Не все сборки, которые присутствуют в changelog,
попадают в репозитарий.

> Но почему-то его запихнули в пакет. Для чего? Почему
> changelog указывается перед сборкой пакета, а не в момент помещения
> его в репозитарий?
Потому что changelog  - это свойство пакета.


> Кроме того, маразм требовать, чтобы из apt приезжали только новые
> пакеты, в смысле версии самого пакета. Ну почему, если выложили новую
> версию openoffice на тестирование в Сизиф, то при серьездных проблемах
> необходимо обязательно ПЕРЕСОБИРАТЬ старую, которая и без того уже
> собрана? (так еще и со сменой serial!!!)
Вы не умеете пользоваться Hold? И не умеете пользоваться архивом Сизифа?
Это ваши проблемы, а не apt или rpm.


> Почему просто не выложить старые бинарные пакеты?
Потому что apt не будет откатывать версию с новой на старую
автоматически. При этом старая версия находится в репозитарии, а новая
- в установленной системе. Это конфликт, который находится вне
репозитария, и решается только с помощью Serial или подъема версии.

> Раз их решили выложить поверх старых, то на
> это есть причины, которые и раскрываться в changelog'е репозитария,
> где случилась коллизия.
Причем тут репозитарий?

> Ну не перед сборкой же это указывать? Ну это
> же маразм! Все-таки changelog описывает не изменения в spec'е (они
> пользователям нафик не нужны и пусть отслеживаются системой контроля
> версий) или исходниках, а изменения самого пакета, по сравнению с
> предыдущим. При этом о предыдущем имеет смысл говорить только в
> контексте репозитария.
Логика ущербна, так как не все сборки попадают в репозитарий.


> Самое главное, к чему, все это приводит -- это невозможность создавать
> альтернативные сборки. А ведь очень хочется... И не только мне! Совсем
> недавно была ругань по поводу альтернативного пакета залитого в
> Daedalus. И всем известны альтернативные ядра... Да много всего. И
> никаких проблем бы не возникало, если бы каждый мог создать свою
> сборку в свой репозитарий, а все желающие могли бы подключить его
> репозитарий с большим приоритетом, чем официальный.
Если вы не умеете подключать репозитарии с приоритетами - это ваши проблемы.

> И число людей
> сделавших такой выбор было бы хорошим аргументом в пользу переноса
> именно его пакетов в официальный репозиторий. И не надо их при этом
> пересобирать, ибо ну нечего там пересобирать... Его надо только
> проверить на совместимость содержимого с библиотеками, но это и так
> будет видно как unmet'ы. Возможно надо будет поменять скрипты
> установки... И что ради этого пересобирать тяжелый пакет?
Ради смены скриптов установки? конечно.

> Но сейчас это не возможно, а одни только лишние пересборки (версию,
> забыл поднять, changelog забыл добавить и т. п.) и огромные проблемы
> создания альтернативного репозитария (разве что называть пакеты другим
> именем, иначе путаются версии, релизы, changelog'и).
Никаких огромных проблем нет, есть просто незнание возможностей того
самого инструментария, который вы так бездумно хаете. Что касается
"лишних пересборок" из-за отсутствия changelog, то rpm -bs спасет
гиганта мысли. Лишние пересборки - лишь средство удостовериться что
пакет соберется, а вовсе не необходимый шаг.

> Вот. Накипело.
Накипайте почаще. Только не обижайтесь, если выяснится, что
большинство ваших проблем вовсе не глобальны, а объясняются банальным
незнанием. Учиться никогда не поздно.

> P. S. Точно не помню кто, но кто-то из Альтов говорил, что rpm -- это
> единственная программа, к которой у него нет притензий. Так вот у меня
> rpm и apt -- программы, к которым у меня больше всего притензий,
> поскольку они системообразующи и косяки в них распространяются на всю
> систему.
Вы не любите кошек? Вы просто не умеете их готовить! (ц)

> P. P. S. К сожалению, на поворот к лучшему даже не надеюсь.
А зря, ведь все уже сделано до вас, в 14 веке. (ц)

Re: [devel] поддержка пакетов в git

[Dmitriy M. Maslennikov]

24 сентября 2008 г. 16:47 пользователь Damir Shayhutdinov
<damir@altlinux.org> написал:
>> Последние два пункта считаю, что необходимо пояснить.
> Правильно, потому что эти два пункта - полнейшая ерунда.
Пока меня в этом не разубедили. Буду только рад, если вы сумеете это сделать.

>> Я так понимаю, что по сути пакет -- это набор файлов со скриптами
>> установки/удаления. Репозитарий набор пакетов, причем удобный для
>> обновления. Changelog -- это история изменения пакета В РЕПОЗИТАРИИ, а
>> не пакета вообще.
> Вот это глупость. Не все сборки, которые присутствуют в changelog,
> попадают в репозитарий.
А изменения чего, по сравнению с чем они тогда описывают? И зачем они
такие нужны? Разве что не мешают сильно... Хотя я могу представить,
что пользователь может захотеть увидеть именно некоторую конкретную
SRPM описанную в истории, и сильно удивиться, что такой никогда не
существовало, но перед этим существенно намучается с ее поском, задаст
вопросы в рассылках, поматериться, наконец.

>> Но почему-то его запихнули в пакет. Для чего? Почему
>> changelog указывается перед сборкой пакета, а не в момент помещения
>> его в репозитарий?
> Потому что changelog  - это свойство пакета.
Если у вас есть просто пакет без истории предыдущих версий, то
changelog от него вам абсолютно не нужен. Смысл changelog появляется
только там, гда вы можете ощутить эти самые change'ы, то есть в
репозитории, или имея папку с хоть каким-то количеством пакетов из
этой истории, либо надежный способ эти пакеты достать. Если же у вас
просто один пакет, то все существенное для пользователя -- это его url
и версия исходников, из которых он был получен. Возможно имя сборщика
(скажем, некоторым вы доверяете, а про некоторых знаете, что собирают
они не очень), история же для пользователя безполезна в этом случае
абсолютно, разве нет?

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

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

>> Кроме того, маразм требовать, чтобы из apt приезжали только новые
>> пакеты, в смысле версии самого пакета. Ну почему, если выложили новую
>> версию openoffice на тестирование в Сизиф, то при серьездных проблемах
>> необходимо обязательно ПЕРЕСОБИРАТЬ старую, которая и без того уже
>> собрана? (так еще и со сменой serial!!!)
> Вы не умеете пользоваться Hold? И не умеете пользоваться архивом Сизифа?
Hold -- действительно не умею, даже не знаю, что это. Архив Сизифа --
это не решение вообще. Вот тут недавно про проблему с xserver большой
тред был. Что ж все эти люди не смогли-то архивом воспользоваться? Это
по вашему правильно, что проблемы мантейнера должны решать
пользователи? Логичнее было, чтобы мантейнер откатил бы версию, а как
с дровами проблема решилась бы, так и выложил свою новую сборку. До
той поры новая версия могла бы полежать в личном репозитарии
мантейнера.

> Это ваши проблемы, а не apt или rpm.
Ну, конечно, я то считал, что компьютер и ПО для пользователя, а
оказывается наоборот

>> Почему просто не выложить старые бинарные пакеты?
> Потому что apt не будет откатывать версию с новой на старую
> автоматически. При этом старая версия находится в репозитарии, а новая
> - в установленной системе. Это конфликт, который находится вне
> репозитария, и решается только с помощью Serial или подъема версии.
Так вот я и говорю, что apt убог и не может это сделать.

>> Раз их решили выложить поверх старых, то на
>> это есть причины, которые и раскрываться в changelog'е репозитария,
>> где случилась коллизия.
> Причем тут репозитарий?
При том, что apt убог, и не может нормально работать с пакетами. При
этом огромная часть его проблем тянется из rpm (ИМХО)

>> И число людей
>> сделавших такой выбор было бы хорошим аргументом в пользу переноса
>> именно его пакетов в официальный репозиторий. И не надо их при этом
>> пересобирать, ибо ну нечего там пересобирать... Его надо только
>> проверить на совместимость содержимого с библиотеками, но это и так
>> будет видно как unmet'ы. Возможно надо будет поменять скрипты
>> установки... И что ради этого пересобирать тяжелый пакет?
> Ради смены скриптов установки? конечно.
Это по вашему не оверхед? Если я в одном символе, где-нибудь в %post в
том же openoffice опечатался, то неприменно должен его пересобрать?

>> Вот. Накипело.
> Накипайте почаще. Только не обижайтесь, если выяснится, что
> большинство ваших проблем вовсе не глобальны, а объясняются банальным
> незнанием. Учиться никогда не поздно.
Так это же хорошо, если мои проблемы не глобальны. Значит я смогу их
быстро разрешить) Только пока не получается и уже давольно долго...
Так что я уже и о их глобальности задумался. Так что давайте выводите
же меня из этого заблуждения.

>> P. S. Точно не помню кто, но кто-то из Альтов говорил, что rpm -- это
>> единственная программа, к которой у него нет притензий. Так вот у меня
>> rpm и apt -- программы, к которым у меня больше всего притензий,
>> поскольку они системообразующи и косяки в них распространяются на всю
>> систему.
> Вы не любите кошек? Вы просто не умеете их готовить! (ц)
Посмотрим)

>> P. P. S. К сожалению, на поворот к лучшему даже не надеюсь.
> А зря, ведь все уже сделано до вас, в 14 веке. (ц)
На мой взгляд не совсем уместная гипербола.

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

Re: [devel] поддержка пакетов в git

[Damir Shayhutdinov]

>>> Я так понимаю, что по сути пакет -- это набор файлов со скриптами
>>> установки/удаления. Репозитарий набор пакетов, причем удобный для
>>> обновления. Changelog -- это история изменения пакета В РЕПОЗИТАРИИ, а
>>> не пакета вообще.
>> Вот это глупость. Не все сборки, которые присутствуют в changelog,
>> попадают в репозитарий.
> А изменения чего, по сравнению с чем они тогда описывают?
Изменения между спектром версий, установленных у пользователя и
версией в репозитарии.


> И зачем они
> такие нужны? Разве что не мешают сильно... Хотя я могу представить,
> что пользователь может захотеть увидеть именно некоторую конкретную
> SRPM описанную в истории, и сильно удивиться, что такой никогда не
> существовало, но перед этим существенно намучается с ее поском, задаст
> вопросы в рассылках, поматериться, наконец.
Пользователь все может захотеть. Но репозитарий - это постоянно
двигающаяся цель. Промежуточные src.rpm, которые были в репозитарии
можно получить через архив.

>>> Но почему-то его запихнули в пакет. Для чего? Почему
>>> changelog указывается перед сборкой пакета, а не в момент помещения
>>> его в репозитарий?
>> Потому что changelog  - это свойство пакета.
> Если у вас есть просто пакет без истории предыдущих версий, то
> changelog от него вам абсолютно не нужен. Смысл changelog появляется
> только там, гда вы можете ощутить эти самые change'ы, то есть в
> репозитории, или имея папку с хоть каким-то количеством пакетов из
> этой истории, либо надежный способ эти пакеты достать.
Это не так. Для первичной установки действительно changelog не нужен.
А вот для обновления - полезен.

> Если же у вас
> просто один пакет, то все существенное для пользователя -- это его url
> и версия исходников, из которых он был получен. Возможно имя сборщика
> (скажем, некоторым вы доверяете, а про некоторых знаете, что собирают
> они не очень), история же для пользователя безполезна в этом случае
> абсолютно, разве нет?
Полезна или бесполезна история - это дело каждого пользователя. Вам
может и бесполезна. А вот мне полезна, потому что с помощью нее я
могу:
1) Принять решение, обновлять мне пакет или нет
2) В случае если обновление чего-то сломало, посмотреть не сказано ли
об этом в changelog.


> Ну что мне даст, что у пакета когда-то была другая сборка, если мне и
> взять то из нее неоткуда, а если и есть рядом какой пакет с подходящей
> версией, то тоже не понятно это та, которая имелась в виду или
> какая-то другая. И только центральный репозиторий с четким
> версионированием может придать смысл истории изменений.
Вы просто не понимаете простого факта - репозитарий - это не статичная
вещь. Это постоянно изменяющаяся сущность. У пользователя на
компьютере могут быть пакеты таких версий, которых уже нет в
репозитарии.

То есть вы думаете что есть только пакет в репозитарии (самой
последней версии), а на самом деле, есть пакет в репозитарии + весь
спектр предыдущих версий пакета, установленных в системах различных
пользователей.


> Из вышесказанных соображений заключаю, что история пакета бессмыслена,
> если я не знаю к какому репозиторию она относиться, что и позволяет
> мне считать ее свойством именно репозитория.
К множеству пакетов репозитария надо приплюсовать множество
установленных в системе пакетов. Для этой системы история changelog
имеет смысл.


>>> Кроме того, маразм требовать, чтобы из apt приезжали только новые
>>> пакеты, в смысле версии самого пакета. Ну почему, если выложили новую
>>> версию openoffice на тестирование в Сизиф, то при серьездных проблемах
>>> необходимо обязательно ПЕРЕСОБИРАТЬ старую, которая и без того уже
>>> собрана? (так еще и со сменой serial!!!)
>> Вы не умеете пользоваться Hold? И не умеете пользоваться архивом Сизифа?
> Hold -- действительно не умею, даже не знаю, что это.
Вот видите, вы инструментом не владеете, а хаете почем зря. Выглядит
это некрасиво. Как ругать автомобиль за то, что в нем нет задней
передачи, если не умеете пользоваться ручкой переключения передач. Вы
думаете это проблема производителя автомобиля?

> Архив Сизифа -- это не решение вообще.
Вы вот зря стучите ложкой. Архив Сизифа - отличное решение для
проблемы "ой, а я сделал дистапгрейд и у меня все сломалось, верните
все взад".

> Вот тут недавно про проблему с xserver большой
> тред был. Что ж все эти люди не смогли-то архивом воспользоваться?
Могли, и наверняка воспользовались. Просто им хочется участвовать в
развитии репозитария, а не сидеть на какой-то более-менее стабильной
архивной версии. В рамках развития репозитария решение с архивом
Сизифа конечно несистемно и неконструктивно.

> Это
> по вашему правильно, что проблемы мантейнера должны решать
> пользователи? Логичнее было, чтобы мантейнер откатил бы версию, а как
> с дровами проблема решилась бы, так и выложил свою новую сборку.
Боюсь в данном конкретном случае такое решение невозможно, так как
ситуация с дровами никогда не решится. Проприетарщики не будут
выпускать свои старые дрова для нового xorg. Им выгодно, чтобы старые
версии карт оставались неподдерживаемыми, и люди делали апгрейд.

Кстати, я вот пользуюсь драйвером ati для моего X1400 - отлично
работает 3D и вообще ускорение. Проприетарным драйвером пользоваться
невозможно - настолько он глючный.


> До той поры новая версия могла бы полежать в личном репозитарии
> мантейнера.
Она там и лежала - никто не жаловался.

>> Это ваши проблемы, а не apt или rpm.
> Ну, конечно, я то считал, что компьютер и ПО для пользователя, а
> оказывается наоборот
Прежде чем чего-то хаять, сначала изучите. Вдруг, магическим образом,
ваши проблемы могут быть решены без вашего радикального "отнять и
поделить".


>>> Почему просто не выложить старые бинарные пакеты?
>> Потому что apt не будет откатывать версию с новой на старую
>> автоматически. При этом старая версия находится в репозитарии, а новая
>> - в установленной системе. Это конфликт, который находится вне
>> репозитария, и решается только с помощью Serial или подъема версии.
> Так вот я и говорю, что apt убог и не может это сделать.

А я говорю что апт может это сделать на компьютере отдельного
пользователя, но общесистемно в рамках дистрибутива можно делать
только через Serial.  А все из-за того что вы не учитываете
установленные в системе пакеты.

>>> Раз их решили выложить поверх старых, то на
>>> это есть причины, которые и раскрываться в changelog'е репозитария,
>>> где случилась коллизия.
>> Причем тут репозитарий?
> При том, что apt убог, и не может нормально работать с пакетами. При
> этом огромная часть его проблем тянется из rpm (ИМХО)

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

>> Ради смены скриптов установки? конечно.
> Это по вашему не оверхед? Если я в одном символе, где-нибудь в %post в
> том же openoffice опечатался, то неприменно должен его пересобрать?
Если вы не умеете по-другому - то таки да.
(hint: rpm -bb --short-circuit может помочь)
Почитайте побольше про rpm чтоли :)


>>> Вот. Накипело.
>> Накипайте почаще. Только не обижайтесь, если выяснится, что
>> большинство ваших проблем вовсе не глобальны, а объясняются банальным
>> незнанием. Учиться никогда не поздно.
> Так это же хорошо, если мои проблемы не глобальны. Значит я смогу их
> быстро разрешить) Только пока не получается и уже давольно долго...
Вы пришли по адресу. Вам помогут :)

http://www.altlinux.org/Советы_по_использованию_APT (раздел Обновление
системы "вниз" )
man apt_preferences

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

Re: [devel] поддержка пакетов в git

[Dmitriy M. Maslennikov]

24 сентября 2008 г. 18:42 пользователь Damir Shayhutdinov
<damir@altlinux.org> написал:
>> А изменения чего, по сравнению с чем они тогда описывают?
> Изменения между спектром версий, установленных у пользователя и
> версией в репозитарии.
Еще раз. Если у нас есть репазиторий, то в changelog'е у нас изменения
пакета в этом репозитории. Если у нас просто пакет, то changelog
теряет смысл, поскольку неизвестно из какого он репозитория. Поэтому я
и задаюсь вопросом, если репозиторий так важен для changeloga, то
почему он находится в пакете?

>> И зачем они
>> такие нужны? Разве что не мешают сильно... Хотя я могу представить,
>> что пользователь может захотеть увидеть именно некоторую конкретную
>> SRPM описанную в истории, и сильно удивиться, что такой никогда не
>> существовало, но перед этим существенно намучается с ее поском, задаст
>> вопросы в рассылках, поматериться, наконец.
> Пользователь все может захотеть. Но репозитарий - это постоянно
> двигающаяся цель. Промежуточные src.rpm, которые были в репозитарии
> можно получить через архив.
Еще раз. Вы сказали, что в changelog'е могут оказаться записи, которые
не соответствуют ни одной из RPM оказавшихся в репозитории (о тестовой
сборке мантейнера). Так вот мой вопрос был о том, зачем такие записи
нужны, ибо они только сбивают с толку, поскольку никакие архивы таких
пакетов не содержат. Именно поэтому я считаю разумным писать изменения
именно при выкладывании пакета, так как в таком случае будет строгое
соответствие между изменениями в пакете и пакетами.

> Это не так. Для первичной установки действительно changelog не нужен.
> А вот для обновления - полезен.
Еще раз. Если у вас стоит пакет из официального репозитория и вы
пытаетесь его обновить, то changelog содержит интересную для вас
информацию. Если же у вас самосборный пакет или пакет из другого
репозитория, то он теряет всякий смысл. именно поэтому changelog --
это именно своийство конкретного репозитория, а не пакета самого по
себе, поскольку changelog описывает изменения, которых нет у пакета в
отрыве от репозитория.

> Полезна или бесполезна история - это дело каждого пользователя. Вам
> может и бесполезна. А вот мне полезна, потому что с помощью нее я
> могу:
> 1) Принять решение, обновлять мне пакет или нет
> 2) В случае если обновление чего-то сломало, посмотреть не сказано ли
> об этом в changelog.
Вот именно, но только в случае если у вас только один репозитарий.
Если у вас есть пакет в котором что-то глючит, а друг вам приносит на
флешке пакет(тот же самый но совсем от другого сборщика) и уверяет,
что там этого глюка нет, то changelog для вас абсолютно бесполезен.
Так как этот пакет может иметь совсем другую историю и в нем такого
бага нет и не было, соответственно и упоминания в changelog о нем тоже
нет. Changelog полезен, но только как свойство пакета в конкретном
репозитории, а не как свойство пакета вообще.

> Вы просто не понимаете простого факта - репозитарий - это не статичная
> вещь. Это постоянно изменяющаяся сущность. У пользователя на
> компьютере могут быть пакеты таких версий, которых уже нет в
> репозитарии.
Не вижу в этом никакой проблемы. Как не вижу проблемы в том, что у
пользователя есть пакеты, которых никогда в репозитарии и не было.

> То есть вы думаете что есть только пакет в репозитарии (самой
> последней версии), а на самом деле, есть пакет в репозитарии + весь
> спектр предыдущих версий пакета, установленных в системах различных
> пользователей.
Нет я так не думаю. Я думаю что есть великое множество пакетов,
собранных разными людьми, для разных целей, с разными требованиями и
разным результатом. И не понимаю о каком changelog'е в таком случае
идет речь. Но некоторые из этих пакетов попадают в репозитарий, с
которого их берет много людей и для их удобства необходимо каждый раз
при замене пакета писать, для чего эта замена производилась и что
теперь поменяется и что от этого стоит ожидать. И з этой информации и
должна формироваться история конкретного пакета в конкретном
репозитарии.

>> Из вышесказанных соображений заключаю, что история пакета бессмыслена,
>> если я не знаю к какому репозиторию она относиться, что и позволяет
>> мне считать ее свойством именно репозитория.
> К множеству пакетов репозитария надо приплюсовать множество
> установленных в системе пакетов. Для этой системы история changelog
> имеет смысл.
Имеет смысл, если все эти пакеты были из этого репозитария. Так вот и
пусть хранится в репозитарии и показывается apt'ом при запросе. А вот
в rpm такой сущности не место.

>> Hold -- действительно не умею, даже не знаю, что это.
> Вот видите, вы инструментом не владеете, а хаете почем зря. Выглядит
> это некрасиво. Как ругать автомобиль за то, что в нем нет задней
> передачи, если не умеете пользоваться ручкой переключения передач. Вы
> думаете это проблема производителя автомобиля?
Вы уверены, что "Hold" решает все названые мной проблемы apt?

>> Архив Сизифа -- это не решение вообще.
> Вы вот зря стучите ложкой. Архив Сизифа - отличное решение для
> проблемы "ой, а я сделал дистапгрейд и у меня все сломалось, верните
> все взад".
Зато совсем некудышнее в случае: "Ой, я залил в Сизиф пакет, который у
всех все ломает, как мне вернуть все взад?"

>> Вот тут недавно про проблему с xserver большой
>> тред был. Что ж все эти люди не смогли-то архивом воспользоваться?
> Могли, и наверняка воспользовались. Просто им хочется участвовать в
> развитии репозитария, а не сидеть на какой-то более-менее стабильной
> архивной версии. В рамках развития репозитария решение с архивом
> Сизифа конечно несистемно и неконструктивно.
Неконструктивно ломать его надолго. Я понимаю, что Сизиф нестабилен,
но очень неприятно, когда он ломается больше чем на день.

>> Это
>> по вашему правильно, что проблемы мантейнера должны решать
>> пользователи? Логичнее было, чтобы мантейнер откатил бы версию, а как
>> с дровами проблема решилась бы, так и выложил свою новую сборку.
> Боюсь в данном конкретном случае такое решение невозможно, так как
> ситуация с дровами никогда не решится. Проприетарщики не будут
> выпускать свои старые дрова для нового xorg. Им выгодно, чтобы старые
> версии карт оставались неподдерживаемыми, и люди делали апгрейд.
Боюсь, что все-таки сделают. Но в любом случае время покажет. В данном
случае мантейнер, по-моему, все-таки поторопился, но сейчас не об
этом.

> Кстати, я вот пользуюсь драйвером ati для моего X1400 - отлично
> работает 3D и вообще ускорение. Проприетарным драйвером пользоваться
> невозможно - настолько он глючный.
Дело даже не в драйверах, а в том, что автоматика по определению
правильного драйвера отказала, это раз, открытого драйвера для nvidia
с 3D в Сизифе нет, это два. Так что можно было хотя бы решить эти два
вопроса. А до их решения откатить пакет. А то вот мне пришлось
отрубить всю автоматику и настраивать вручную. И я не знаю, работает
ли она сейчас. Поскольку ее проверка совсем не то, чем я хочу
заниматься ежедневно.

>> До той поры новая версия могла бы полежать в личном репозитарии
>> мантейнера.
> Она там и лежала - никто не жаловался.
Не, там ее никто не смотрел(ну почти). Как только ее выложили в Сизиф,
то посыпались жалобы. Надо было ее быстро откатить, починить, что
возможно, и снова выложить. Но это очень трудоемко, а могло бы быть
легко, если бы apt умел работать по-иному.

> Прежде чем чего-то хаять, сначала изучите. Вдруг, магическим образом,
> ваши проблемы могут быть решены без вашего радикального "отнять и
> поделить".
Так вот уже несколько лет изучаю, а все никак не доросту.

> А я говорю что апт может это сделать на компьютере отдельного
> пользователя, но общесистемно в рамках дистрибутива можно делать
> только через Serial.  А все из-за того что вы не учитываете
> установленные в системе пакеты.
Не понимаю, как пакеты установленные у пользователя мешают нормальной
работе репозитория.

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

>> Это по вашему не оверхед? Если я в одном символе, где-нибудь в %post в
>> том же openoffice опечатался, то неприменно должен его пересобрать?
> Если вы не умеете по-другому - то таки да.
> (hint: rpm -bb --short-circuit может помочь)
> Почитайте побольше про rpm чтоли :)
Про "--short-circuit" я знаю. Только hasher и Incominger так не умеют.

>> Так это же хорошо, если мои проблемы не глобальны. Значит я смогу их
>> быстро разрешить) Только пока не получается и уже давольно долго...
> Вы пришли по адресу. Вам помогут :)
Вот уж спасибо.

> http://www.altlinux.org/Советы_по_использованию_APT (раздел Обновление
> системы "вниз" )
> man apt_preferences

>> Так что я уже и о их глобальности задумался. Так что давайте выводите
>> же меня из этого заблуждения.
> Я могу лишь показать направление. Выйти должны вы сами.
Пока что направление выглядит не убедительно. У меня впечатление, что
прямо по нему стена. И я в нее уже бился.

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

Re: [devel] поддержка пакетов в git

[Led]

On Wednesday, 24 September 2008 18:52:20 Dmitriy M. Maslennikov wrote:
> 24 сентября 2008 г. 18:42 пользователь Damir Shayhutdinov
>
> <damir@altlinux.org> написал:
> >> А изменения чего, по сравнению с чем они тогда описывают?
> >
> > Изменения между спектром версий, установленных у пользователя и
> > версией в репозитарии.
>
> Еще раз. Если у нас есть репазиторий, то в changelog'е у нас изменения
> пакета в этом репозитории. Если у нас просто пакет, то changelog
> теряет смысл, поскольку неизвестно из какого он репозитория. Поэтому я
> и задаюсь вопросом, если репозиторий так важен для changeloga, то
> почему он находится в пакете?
>
> >> И зачем они
> >> такие нужны? Разве что не мешают сильно... Хотя я могу представить,
> >> что пользователь может захотеть увидеть именно некоторую конкретную
> >> SRPM описанную в истории, и сильно удивиться, что такой никогда не
> >> существовало, но перед этим существенно намучается с ее поском, задаст
> >> вопросы в рассылках, поматериться, наконец.
> >
> > Пользователь все может захотеть. Но репозитарий - это постоянно
> > двигающаяся цель. Промежуточные src.rpm, которые были в репозитарии
> > можно получить через архив.
>
> Еще раз. Вы сказали, что в changelog'е могут оказаться записи, которые
> не соответствуют ни одной из RPM оказавшихся в репозитории (о тестовой
> сборке мантейнера). Так вот мой вопрос был о том, зачем такие записи
> нужны, ибо они только сбивают с толку, поскольку никакие архивы таких
> пакетов не содержат. Именно поэтому я считаю разумным писать изменения
> именно при выкладывании пакета, так как в таком случае будет строгое
> соответствие между изменениями в пакете и пакетами.
>
> > Это не так. Для первичной установки действительно changelog не нужен.
> > А вот для обновления - полезен.
>
> Еще раз. Если у вас стоит пакет из официального репозитория и вы
> пытаетесь его обновить, то changelog содержит интересную для вас
> информацию. Если же у вас самосборный пакет или пакет из другого
> репозитория, то он теряет всякий смысл. именно поэтому changelog --
> это именно своийство конкретного репозитория, а не пакета самого по
> себе, поскольку changelog описывает изменения, которых нет у пакета в
> отрыве от репозитория.
>
> > Полезна или бесполезна история - это дело каждого пользователя. Вам
> > может и бесполезна. А вот мне полезна, потому что с помощью нее я
> > могу:
> > 1) Принять решение, обновлять мне пакет или нет
> > 2) В случае если обновление чего-то сломало, посмотреть не сказано ли
> > об этом в changelog.
>
> Вот именно, но только в случае если у вас только один репозитарий.
> Если у вас есть пакет в котором что-то глючит, а друг вам приносит на
> флешке пакет(тот же самый но совсем от другого сборщика) и уверяет,
> что там этого глюка нет, то changelog для вас абсолютно бесполезен.
> Так как этот пакет может иметь совсем другую историю и в нем такого
> бага нет и не было, соответственно и упоминания в changelog о нем тоже
> нет. Changelog полезен, но только как свойство пакета в конкретном
> репозитории, а не как свойство пакета вообще.
>
> > Вы просто не понимаете простого факта - репозитарий - это не статичная
> > вещь. Это постоянно изменяющаяся сущность. У пользователя на
> > компьютере могут быть пакеты таких версий, которых уже нет в
> > репозитарии.
>
> Не вижу в этом никакой проблемы. Как не вижу проблемы в том, что у
> пользователя есть пакеты, которых никогда в репозитарии и не было.
>
> > То есть вы думаете что есть только пакет в репозитарии (самой
> > последней версии), а на самом деле, есть пакет в репозитарии + весь
> > спектр предыдущих версий пакета, установленных в системах различных
> > пользователей.
>
> Нет я так не думаю. Я думаю что есть великое множество пакетов,
> собранных разными людьми, для разных целей, с разными требованиями и
> разным результатом. И не понимаю о каком changelog'е в таком случае
> идет речь. Но некоторые из этих пакетов попадают в репозитарий, с
> которого их берет много людей и для их удобства необходимо каждый раз
> при замене пакета писать, для чего эта замена производилась и что
> теперь поменяется и что от этого стоит ожидать. И з этой информации и
> должна формироваться история конкретного пакета в конкретном
> репозитарии.
>
> >> Из вышесказанных соображений заключаю, что история пакета бессмыслена,
> >> если я не знаю к какому репозиторию она относиться, что и позволяет
> >> мне считать ее свойством именно репозитория.
> >
> > К множеству пакетов репозитария надо приплюсовать множество
> > установленных в системе пакетов. Для этой системы история changelog
> > имеет смысл.
>
> Имеет смысл, если все эти пакеты были из этого репозитария. Так вот и
> пусть хранится в репозитарии и показывается apt'ом при запросе. А вот
> в rpm такой сущности не место.
>
> >> Hold -- действительно не умею, даже не знаю, что это.
> >
> > Вот видите, вы инструментом не владеете, а хаете почем зря. Выглядит
> > это некрасиво. Как ругать автомобиль за то, что в нем нет задней
> > передачи, если не умеете пользоваться ручкой переключения передач. Вы
> > думаете это проблема производителя автомобиля?
>
> Вы уверены, что "Hold" решает все названые мной проблемы apt?
>
> >> Архив Сизифа -- это не решение вообще.
> >
> > Вы вот зря стучите ложкой. Архив Сизифа - отличное решение для
> > проблемы "ой, а я сделал дистапгрейд и у меня все сломалось, верните
> > все взад".
>
> Зато совсем некудышнее в случае: "Ой, я залил в Сизиф пакет, который у
> всех все ломает, как мне вернуть все взад?"
>
> >> Вот тут недавно про проблему с xserver большой
> >> тред был. Что ж все эти люди не смогли-то архивом воспользоваться?
> >
> > Могли, и наверняка воспользовались. Просто им хочется участвовать в
> > развитии репозитария, а не сидеть на какой-то более-менее стабильной
> > архивной версии. В рамках развития репозитария решение с архивом
> > Сизифа конечно несистемно и неконструктивно.
>
> Неконструктивно ломать его надолго. Я понимаю, что Сизиф нестабилен,
> но очень неприятно, когда он ломается больше чем на день.
>
> >> Это
> >> по вашему правильно, что проблемы мантейнера должны решать
> >> пользователи? Логичнее было, чтобы мантейнер откатил бы версию, а как
> >> с дровами проблема решилась бы, так и выложил свою новую сборку.
> >
> > Боюсь в данном конкретном случае такое решение невозможно, так как
> > ситуация с дровами никогда не решится. Проприетарщики не будут
> > выпускать свои старые дрова для нового xorg. Им выгодно, чтобы старые
> > версии карт оставались неподдерживаемыми, и люди делали апгрейд.
>
> Боюсь, что все-таки сделают. Но в любом случае время покажет. В данном
> случае мантейнер, по-моему, все-таки поторопился, но сейчас не об
> этом.
>
> > Кстати, я вот пользуюсь драйвером ati для моего X1400 - отлично
> > работает 3D и вообще ускорение. Проприетарным драйвером пользоваться
> > невозможно - настолько он глючный.
>
> Дело даже не в драйверах, а в том, что автоматика по определению
> правильного драйвера отказала, это раз, открытого драйвера для nvidia
> с 3D в Сизифе нет, это два. Так что можно было хотя бы решить эти два
> вопроса. А до их решения откатить пакет. А то вот мне пришлось
> отрубить всю автоматику и настраивать вручную. И я не знаю, работает
> ли она сейчас. Поскольку ее проверка совсем не то, чем я хочу
> заниматься ежедневно.
>
> >> До той поры новая версия могла бы полежать в личном репозитарии
> >> мантейнера.
> >
> > Она там и лежала - никто не жаловался.
>
> Не, там ее никто не смотрел(ну почти). Как только ее выложили в Сизиф,
> то посыпались жалобы. Надо было ее быстро откатить, починить, что
> возможно, и снова выложить. Но это очень трудоемко, а могло бы быть
> легко, если бы apt умел работать по-иному.
>
> > Прежде чем чего-то хаять, сначала изучите. Вдруг, магическим образом,
> > ваши проблемы могут быть решены без вашего радикального "отнять и
> > поделить".
>
> Так вот уже несколько лет изучаю, а все никак не доросту.
>
> > А я говорю что апт может это сделать на компьютере отдельного
> > пользователя, но общесистемно в рамках дистрибутива можно делать
> > только через Serial.  А все из-за того что вы не учитываете
> > установленные в системе пакеты.
>
> Не понимаю, как пакеты установленные у пользователя мешают нормальной
> работе репозитория.
>
> > Если вы можете - поясните пожалуйста свою точку зрения. Пока это
> > голословные утверждения, если не сказать жестче.
>
> Так я и стараюсь пояснить. Может и не понятно, так давайте попробуем
> разобраться.
>
> >> Это по вашему не оверхед? Если я в одном символе, где-нибудь в %post в
> >> том же openoffice опечатался, то неприменно должен его пересобрать?
> >
> > Если вы не умеете по-другому - то таки да.
> > (hint: rpm -bb --short-circuit может помочь)
> > Почитайте побольше про rpm чтоли :)
>
> Про "--short-circuit" я знаю. Только hasher и Incominger так не умеют.

hasher - умеет.

-- 
Led

Re: [devel] поддержка пакетов в git

[Andrey Rahmatullin]

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

On Wed, Sep 24, 2008 at 08:14:50PM +0300, Led wrote:
> On Wednesday, 24 September 2008 18:52:20 Dmitriy M. Maslennikov wrote:
188 строк
> 
> hasher - умеет.
> 

-- 
WBR, wRAR (ALT Linux Team)
Powered by the ALT Linux fortune(8):

А есть желающие бежать в переди поезда? Так могу помочь -- патчи
очень легко лягут в sim.
		-- icesik in smoke-room@

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

Re: [devel] поддержка пакетов в git

[Anton Farygin]

Andrey Rahmatullin пишет:
> On Wed, Sep 24, 2008 at 08:14:50PM +0300, Led wrote:
>> On Wednesday, 24 September 2008 18:52:20 Dmitriy M. Maslennikov wrote:
> 188 строк

Класс.. мне тоже понравилось.

Re: [devel] поддержка пакетов в git

[Andrey Rahmatullin]

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

On Wed, Sep 24, 2008 at 09:36:10PM +0400, Anton Farygin wrote:
> > 188 строк
> Класс.. мне тоже понравилось.
По твоим письмам такую статистику я тоже иногда показываю.

-- 
WBR, wRAR (ALT Linux Team)
Powered by the ALT Linux fortune(8):

> Зачем вообще делать такую удобную схему поддержки разных
> конфигураций ядра, а потом ее фактически засекречивать?
"Не стоит искать умысла там, где всё объясняет разгильдяйство".
У нас же тут разгильдия майнтейнеров, и каждый норовит что-то
делать, а вот документировать -- только в крайнем случае.
		-- mike in sisyphus@

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

Re: [devel] поддержка пакетов в git

[Anton Farygin]

Andrey Rahmatullin пишет:
> On Wed, Sep 24, 2008 at 09:36:10PM +0400, Anton Farygin wrote:
>>> 188 строк
>> Класс.. мне тоже понравилось.
> По твоим письмам такую статистику я тоже иногда показываю.

ну так она мне тоже нравится.

Re: [devel] поддержка пакетов в git

[Led]

On Wednesday, 24 September 2008 20:36:10 Anton Farygin wrote:
> Andrey Rahmatullin пишет:
> > On Wed, Sep 24, 2008 at 08:14:50PM +0300, Led wrote:
> >> On Wednesday, 24 September 2008 18:52:20 Dmitriy M. Maslennikov wrote:
> >
> > 188 строк
>
> Класс.. мне тоже понравилось.

Заметил только когда отправил уже. Виноват, моя ошибка, прошу прощения

-- 
Led

Re: [devel] поддержка пакетов в git

[Anton Farygin]

Led пишет:
> On Wednesday, 24 September 2008 20:36:10 Anton Farygin wrote:
>> Andrey Rahmatullin пишет:
>>> On Wed, Sep 24, 2008 at 08:14:50PM +0300, Led wrote:
>>>> On Wednesday, 24 September 2008 18:52:20 Dmitriy M. Maslennikov wrote:
>>> 188 строк
>> Класс.. мне тоже понравилось.
> 
> Заметил только когда отправил уже. Виноват, моя ошибка, прошу прощения

Ты не поверишь, но твоё письмо заставило перечитать _всё_, ибо я думал, 
что там где-то кроется ответ.

Отлично, спасибо.

Re: [devel] поддержка пакетов в git

[Damir Shayhutdinov]

>>> А изменения чего, по сравнению с чем они тогда описывают?
>> Изменения между спектром версий, установленных у пользователя и
>> версией в репозитарии.
> Еще раз. Если у нас есть репазиторий, то в changelog'е у нас изменения
> пакета в этом репозитории. Если у нас просто пакет, то changelog
> теряет смысл, поскольку неизвестно из какого он репозитория.
Обоснуйте.

> Поэтому я и задаюсь вопросом, если репозиторий так важен для changeloga, то
> почему он находится в пакете?
Откуда тезис "репозиторий так важен для changeloga"?


>> Пользователь все может захотеть. Но репозитарий - это постоянно
>> двигающаяся цель. Промежуточные src.rpm, которые были в репозитарии
>> можно получить через архив.
> Еще раз. Вы сказали, что в changelog'е могут оказаться записи, которые
> не соответствуют ни одной из RPM оказавшихся в репозитории (о тестовой
> сборке мантейнера). Так вот мой вопрос был о том, зачем такие записи
> нужны, ибо они только сбивают с толку, поскольку никакие архивы таких
> пакетов не содержат. Именно поэтому я считаю разумным писать изменения
> именно при выкладывании пакета, так как в таком случае будет строгое
> соответствие между изменениями в пакете и пакетами.
Это внутреннее дело каждого мантейнера. Несмотря на то, что эти версии
могут никогда не оказаться в основном репозитарии, они могут быть в
репозитарии на people и еще где-нибудь. Для всех сборок, которые могут
оказаться у пользователей, запись в changelog должна быть.


> Еще раз. Если у вас стоит пакет из официального репозитория и вы
> пытаетесь его обновить, то changelog содержит интересную для вас
> информацию. Если же у вас самосборный пакет или пакет из другого
> репозитория, то он теряет всякий смысл. именно поэтому changelog --
> это именно своийство конкретного репозитория, а не пакета самого по
> себе, поскольку changelog описывает изменения, которых нет у пакета в
> отрыве от репозитория.
Этот подход в корне ошибочен и опровергается простым фактом того, что
например пакеты могут быть в разных репозитариях.
И что возможно например перекладывать пакеты из Сизифа в бранч.

На мой взгляд, вы путаете backport/updates policy, причина которого -
в возможности обновиться из бранча до Сизифа.
Связь changelog-repository существует только у вас в голове

>> Полезна или бесполезна история - это дело каждого пользователя. Вам
>> может и бесполезна. А вот мне полезна, потому что с помощью нее я
>> могу:
>> 1) Принять решение, обновлять мне пакет или нет
>> 2) В случае если обновление чего-то сломало, посмотреть не сказано ли
>> об этом в changelog.
> Вот именно, но только в случае если у вас только один репозитарий.
> Если у вас есть пакет в котором что-то глючит, а друг вам приносит на
> флешке пакет(тот же самый но совсем от другого сборщика) и уверяет,
> что там этого глюка нет, то changelog для вас абсолютно бесполезен.
Прошу прощения, но вы говорите о несоотвествии changelog и пакета? Это
проблема конкретного сборщика.

> Так как этот пакет может иметь совсем другую историю и в нем такого
> бага нет и не было, соответственно и упоминания в changelog о нем тоже
> нет. Changelog полезен, но только как свойство пакета в конкретном
> репозитории, а не как свойство пакета вообще.
Вы под словом репозитарий подразумеваете дистрибутив? Определитесь с
терминологией.


>> То есть вы думаете что есть только пакет в репозитарии (самой
>> последней версии), а на самом деле, есть пакет в репозитарии + весь
>> спектр предыдущих версий пакета, установленных в системах различных
>> пользователей.
> Нет я так не думаю. Я думаю что есть великое множество пакетов,
> собранных разными людьми, для разных целей, с разными требованиями и
> разным результатом.
В одном репозитарии?

> И не понимаю о каком changelog'е в таком случае
> идет речь. Но некоторые из этих пакетов попадают в репозитарий, с
> которого их берет много людей и для их удобства необходимо каждый раз
> при замене пакета писать, для чего эта замена производилась и что
> теперь поменяется и что от этого стоит ожидать. И з этой информации и
> должна формироваться история конкретного пакета в конкретном
> репозитарии.
Пока с терминологией вопрос не утрясется - ответ не будет иметь для
вас никакого смысла.
Лично я считаю что сказал достаточно, чтобы слушающий услышал.

>>> Hold -- действительно не умею, даже не знаю, что это.
>> Вот видите, вы инструментом не владеете, а хаете почем зря. Выглядит
>> это некрасиво. Как ругать автомобиль за то, что в нем нет задней
>> передачи, если не умеете пользоваться ручкой переключения передач. Вы
>> думаете это проблема производителя автомобиля?
> Вы уверены, что "Hold" решает все названые мной проблемы apt?
Попробуйте и скажите.

>>> Архив Сизифа -- это не решение вообще.
>> Вы вот зря стучите ложкой. Архив Сизифа - отличное решение для
>> проблемы "ой, а я сделал дистапгрейд и у меня все сломалось, верните
>> все взад".
> Зато совсем некудышнее в случае: "Ой, я залил в Сизиф пакет, который у
> всех все ломает, как мне вернуть все взад?"
В этом отношение решение одно - чинить.

> Неконструктивно ломать его надолго. Я понимаю, что Сизиф нестабилен,
> но очень неприятно, когда он ломается больше чем на день.
У меня ничего не сломалось.  Что я делаю не так?

>> Кстати, я вот пользуюсь драйвером ati для моего X1400 - отлично
>> работает 3D и вообще ускорение. Проприетарным драйвером пользоваться
>> невозможно - настолько он глючный.
> Дело даже не в драйверах, а в том, что автоматика по определению
> правильного драйвера отказала, это раз, открытого драйвера для nvidia
> с 3D в Сизифе нет, это два. Так что можно было хотя бы решить эти два
> вопроса. А до их решения откатить пакет. А то вот мне пришлось
> отрубить всю автоматику и настраивать вручную. И я не знаю, работает
> ли она сейчас. Поскольку ее проверка совсем не то, чем я хочу
> заниматься ежедневно.
На мой взгляд, когда меняется ABI - автоматика тут вообще побоку.

>>> До той поры новая версия могла бы полежать в личном репозитарии
>>> мантейнера.
>> Она там и лежала - никто не жаловался.
> Не, там ее никто не смотрел(ну почти). Как только ее выложили в Сизиф,
> то посыпались жалобы. Надо было ее быстро откатить, починить, что
> возможно, и снова выложить. Но это очень трудоемко, а могло бы быть
> легко, если бы apt умел работать по-иному.
Он все умеет, просто вы не умеете работать по-иному.

>> Прежде чем чего-то хаять, сначала изучите. Вдруг, магическим образом,
>> ваши проблемы могут быть решены без вашего радикального "отнять и
>> поделить".
> Так вот уже несколько лет изучаю, а все никак не доросту.
Я вам сочувствую, но в результате этого обсуждения мне стало понятно,
почему вы не дорастете.
Боюсь вы просто не слушаете того, что вам говорят.

>> А я говорю что апт может это сделать на компьютере отдельного
>> пользователя, но общесистемно в рамках дистрибутива можно делать
>> только через Serial.  А все из-за того что вы не учитываете
>> установленные в системе пакеты.
> Не понимаю, как пакеты установленные у пользователя мешают нормальной
> работе репозитория.
Намекну: зачем нужен Serial?

>> Если вы можете - поясните пожалуйста свою точку зрения. Пока это
>> голословные утверждения, если не сказать жестче.
> Так я и стараюсь пояснить. Может и не понятно, так давайте попробуем
> разобраться.
Читайте внимательнее - все было сказано.

>>> Это по вашему не оверхед? Если я в одном символе, где-нибудь в %post в
>>> том же openoffice опечатался, то неприменно должен его пересобрать?
>> Если вы не умеете по-другому - то таки да.
>> (hint: rpm -bb --short-circuit может помочь)
>> Почитайте побольше про rpm чтоли :)
> Про "--short-circuit" я знаю. Только hasher и Incominger так не умеют.
Hasher умеет hsh-shell и hsh-run

>>> Так что я уже и о их глобальности задумался. Так что давайте выводите
>>> же меня из этого заблуждения.
>> Я могу лишь показать направление. Выйти должны вы сами.
> Пока что направление выглядит не убедительно. У меня впечатление, что
> прямо по нему стена. И я в нее уже бился.
Try harder.

Re: [devel] поддержка пакетов в git

[Dmitriy M. Maslennikov]

24 сентября 2008 г. 21:28 пользователь Damir Shayhutdinov
<lost404@gmail.com> написал:
>> Еще раз. Если у нас есть репазиторий, то в changelog'е у нас изменения
>> пакета в этом репозитории. Если у нас просто пакет, то changelog
>> теряет смысл, поскольку неизвестно из какого он репозитория.
> Обоснуйте.
>
>> Поэтому я и задаюсь вопросом, если репозиторий так важен для changeloga, то
>> почему он находится в пакете?
> Откуда тезис "репозиторий так важен для changeloga"?
По-моему вы настолько сизифоцентричны, что просто не понимаете, что я
имею в виду возможность сборки пакета для Альта, но не для Сизифа(4.0,
4.1 и т. д.), а просто так для себя, для знакомого, для организации,
для стороннего репозитория. Так вот, если я собрал для себя пакет
foo-0.0.1-alt1, потом, пересобирал его, получил некоторый
foo-X.X.X-altX. Он накопил историю в changelog. Теперь этот пакет
собрал кто-то другой в Сизиф. Там пакет тоже развивается и тоже
накапливается историю. Теперь представляем человека, который сначала
взял у меня сторонний пакет, а затем обновляется и apt предлагает ему
обновить его из сизифа, так как там версия оказалась больше. Он
смотрит в changelog в надежде узнать, а стоит ли его обновлять, но что
он узнает из того, совсем другого changelog'а? Да абсолютно неверную
информацию да и только. Информация там описывает изменения пакета в
Сизифе, а у него то он был не оттуда. Именно поэтому я говорю, что
changelog пакета абсолютно бесполезен, если не известно, историю из
какого репозитария он описывает. А если у нас rpm пакет не лежащий в
репозитарии вообще, то его changelog -- это вообще некоторый
абстрактный текст, который вообще ничего конкретного не говорит,
поскольку нет никакой гарантии, что ссылки на пакеты в changelog имеют
в виду пакеты из архива Сизифа, а не из личного архива сборщика. При
этом и версии и релизы могут совпадать, то есть это вообще практически
бесполезная информация. Полезным может являться только описание пакета
со ссылкой на исходники и информацией о примененных патчах, что есть
описание пакета.

>> Еще раз. Если у вас стоит пакет из официального репозитория и вы
>> пытаетесь его обновить, то changelog содержит интересную для вас
>> информацию. Если же у вас самосборный пакет или пакет из другого
>> репозитория, то он теряет всякий смысл. именно поэтому changelog --
>> это именно своийство конкретного репозитория, а не пакета самого по
>> себе, поскольку changelog описывает изменения, которых нет у пакета в
>> отрыве от репозитория.
> Этот подход в корне ошибочен и опровергается простым фактом того, что
> например пакеты могут быть в разных репозитариях.
> И что возможно например перекладывать пакеты из Сизифа в бранч.
Думайте шире. Пакет из Сизифа может быть переложен из этого самого
Сизифа в репозитарий имени Васи Пупкина. При этом запись о том, что в
такой то версии был поправлен такой то баг становиться вызывающе
неверной, так как пакет с этой версией в репозитарии Васи Пупкина
вообще такого бага не содержал.

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

> Вы под словом репозитарий подразумеваете дистрибутив? Определитесь с
> терминологией.
Под репозиторием я понимаю набор пакетов со средствами к их установке
и обновлению.

>> Нет я так не думаю. Я думаю что есть великое множество пакетов,
>> собранных разными людьми, для разных целей, с разными требованиями и
>> разным результатом.
> В одном репозитарии?
Зачем в одном? Вон сколько сторонних репозиториев у Debian'а или у
SuSe. На Сизифе свет клином не сошелся. Хотя пока Альт сильно отстает
по этому параметру (честно говоря я никакого стороннего репозитория
кроме Лакостиса не знаю, бранчи не в счет, people и daedalus
практически не используются и ничего полезного не содержат -- одни
эксперименты)

>> Дело даже не в драйверах, а в том, что автоматика по определению
>> правильного драйвера отказала, это раз, открытого драйвера для nvidia
>> с 3D в Сизифе нет, это два. Так что можно было хотя бы решить эти два
>> вопроса. А до их решения откатить пакет. А то вот мне пришлось
>> отрубить всю автоматику и настраивать вручную. И я не знаю, работает
>> ли она сейчас. Поскольку ее проверка совсем не то, чем я хочу
>> заниматься ежедневно.
> На мой взгляд, когда меняется ABI - автоматика тут вообще побоку.
Видимо мы не поняли друг друга. Под автоматикой я имел сервис
x11_autosetup, который упрямо выставлял мне неработающий драйвер. И
это прекрасно известно и нечего пенять на ABI, просто надо починить
этот сервис, чтобы он хотя бы драйвер nv проставлял.

> Я вам сочувствую, но в результате этого обсуждения мне стало понятно,
> почему вы не дорастете.
> Боюсь вы просто не слушаете того, что вам говорят.
Offtop: ну почему в девеле так часто и быстро переходят на личности???
Ну я то спокойный, а сколько уже ругани тут было. Вопрос конечно
риторический.

>> Не понимаю, как пакеты установленные у пользователя мешают нормальной
>> работе репозитория.
> Намекну: зачем нужен Serial?
Отвечу, что затем, чтобы поднять версию.
Спрошу: а зачем для этого пересобирать пакет?

>> Про "--short-circuit" я знаю. Только hasher и Incominger так не умеют.
> Hasher умеет hsh-shell и hsh-run
То есть, сначала вы советуете использовать --chort-circuit, точнее
категорично заявляете, что я про него не знаю. А затем говорите, что я
его должен использовать через ж... По-моему уметь, и давать
возможность -- это разные вещи. Вот когда я смогу писать gear-hsh -bb
--short-circuit, вот тогда и соглашусь, что инструменты научились это
делать.

Тем не менее это все равно жуткий оверхед. Представьте, что вы
собираете игрушку уровня doom3 -- несколько гигабайт данных. И после
сборки заметили, что и вас один символ в %post скрипте не правильный
(опечатка), сильно вам поможит --short-circuit?

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

Re: [devel] поддержка пакетов в git

[Damir Shayhutdinov]

>> Откуда тезис "репозиторий так важен для changeloga"?
> По-моему вы настолько сизифоцентричны, что просто не понимаете, что я
> имею в виду возможность сборки пакета для Альта, но не для Сизифа(4.0,
> 4.1 и т. д.), а просто так для себя, для знакомого, для организации,
> для стороннего репозитория.
> Так вот, если я собрал для себя пакет
> foo-0.0.1-alt1, потом, пересобирал его, получил некоторый
> foo-X.X.X-altX. Он накопил историю в changelog. Теперь этот пакет
> собрал кто-то другой в Сизиф. Там пакет тоже развивается и тоже
> накапливается историю. Теперь представляем человека, который сначала
> взял у меня сторонний пакет, а затем обновляется и apt предлагает ему
> обновить его из сизифа, так как там версия оказалась больше.
Эта ситуация называется "смешивание репозитариев". Вы делаете эту
операцию на свой страх и риск.
Никаких гарантий на эту операцию никто дать не может.

> Он
> смотрит в changelog в надежде узнать, а стоит ли его обновлять, но что
> он узнает из того, совсем другого changelog'а? Да абсолютно неверную
> информацию да и только. Информация там описывает изменения пакета в
> Сизифе, а у него то он был не оттуда.
В данном случае ситуация абсолютно аналогична поставке этого пакета в
первый раз. Никаких проблем не вижу.

> Именно поэтому я говорю, что
> changelog пакета абсолютно бесполезен, если не известно, историю из
> какого репозитария он описывает.
У вас неверная логическая посылка. Если вы имеете ввиду альтовские
репозитарии - то там все в порядке.
Если вы имеете ввиду какие-то сторонние - то это все равно что в
первый раз ставить. Из-за того, что лично вам это кажется нелогичным,
вовсе не следует что во всем виноват апт или тем более рпм.

> А если у нас rpm пакет не лежащий в
> репозитарии вообще, то его changelog -- это вообще некоторый
> абстрактный текст, который вообще ничего конкретного не говорит,
Любому человеку, умеющему читать, changelog что-нибудь да говорит.

> поскольку нет никакой гарантии, что ссылки на пакеты в changelog имеют
> в виду пакеты из архива Сизифа, а не из личного архива сборщика. При
> этом и версии и релизы могут совпадать, то есть это вообще практически
> бесполезная информация.
Если версии и релизы совпадают - это ошибка упаковки.

> Полезным может являться только описание пакета
> со ссылкой на исходники и информацией о примененных патчах, что есть
> описание пакета.
Эта информация полезна при первой установке пакета.

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

>> Прошу прощения, но вы говорите о несоотвествии changelog и пакета? Это
>> проблема конкретного сборщика.
> Я говорю, что сборщиков может быть много. И у каждого своя история --
> история сборки пакета в конкретный репозитарий.
Тогда это разные пакеты просто.

>> В одном репозитарии?
> Зачем в одном? Вон сколько сторонних репозиториев у Debian'а или у
> SuSe. На Сизифе свет клином не сошелся. Хотя пока Альт сильно отстает
> по этому параметру (честно говоря я никакого стороннего репозитория
> кроме Лакостиса не знаю, бранчи не в счет, people и daedalus
> практически не используются и ничего полезного не содержат -- одни
> эксперименты)
Расскажите, как эту же проблему решили в Дебиане и в Сусе? (И есть ли
вообще проблема?)

>> На мой взгляд, когда меняется ABI - автоматика тут вообще побоку.
> Видимо мы не поняли друг друга. Под автоматикой я имел сервис
> x11_autosetup, который упрямо выставлял мне неработающий драйвер. И
> это прекрасно известно и нечего пенять на ABI, просто надо починить
> этот сервис, чтобы он хотя бы драйвер nv проставлял.
А если удалить драйвера nvidia (все равно они нерабочие)?

>> Я вам сочувствую, но в результате этого обсуждения мне стало понятно,
>> почему вы не дорастете.
>> Боюсь вы просто не слушаете того, что вам говорят.
> Offtop: ну почему в девеле так часто и быстро переходят на личности???
Потому что вы затрагиваете личностные вопросы "не дорасту, не понимаю".

> Ну я то спокойный, а сколько уже ругани тут было. Вопрос конечно
> риторический.
Я очень спокойный, но и мне уже порядком поднадоело объяснять
элементарные вещи повторно.

>>> Не понимаю, как пакеты установленные у пользователя мешают нормальной
>>> работе репозитория.
>> Намекну: зачем нужен Serial?
> Отвечу, что затем, чтобы поднять версию.
Вопрос второй (еще более наводящий) - зачем поднимать версию?

> Спрошу: а зачем для этого пересобирать пакет?
Ответ вытекает напрямую из ответа на второй наводящий вопрос.

>> Про "--short-circuit" я знаю. Только hasher и Incominger так не умеют.
>> Hasher умеет hsh-shell и hsh-run
> То есть, сначала вы советуете использовать --chort-circuit, точнее
> категорично заявляете, что я про него не знаю. А затем говорите, что я
> его должен использовать через ж... По-моему уметь, и давать
> возможность -- это разные вещи. Вот когда я смогу писать gear-hsh -bb
> --short-circuit, вот тогда и соглашусь, что инструменты научились это
> делать.
Гм. У вас тут фундаментальное непонимание чего делает --short-circuit.

> Тем не менее это все равно жуткий оверхед. Представьте, что вы
> собираете игрушку уровня doom3 -- несколько гигабайт данных. И после
> сборки заметили, что и вас один символ в %post скрипте не правильный
> (опечатка), сильно вам поможит --short-circuit?
Сильно поможет. Вы специально придумываете такие примеры?

Re: [devel] поддержка пакетов в git

[Dmitriy M. Maslennikov]

25 сентября 2008 г. 13:22 пользователь Damir Shayhutdinov
<damir@altlinux.org> написал:
> Эта ситуация называется "смешивание репозитариев". Вы делаете эту
> операцию на свой страх и риск.
> Никаких гарантий на эту операцию никто дать не может.
Эта ситуация может быть вполне обычной, если второй репозиторий
специально приспособлен, чтобы быть подключенным к первому. Только в
альтах Сизиф очень не дружелюбен к сторонним репозитариям. Тогда как
дебиан вполне дружелюбен.

>> Именно поэтому я говорю, что
>> changelog пакета абсолютно бесполезен, если не известно, историю из
>> какого репозитария он описывает.
> У вас неверная логическая посылка. Если вы имеете ввиду альтовские
> репозитарии - то там все в порядке.
Я знаю, что в Сизифе все в порядке. Но этот порядок там сейчас
поддерживается вручную. Простая ситуация: мантейнер пакета foo уезжает
в отпуск с ноутом в деревню без инета, где вылизывает новую версию
этого пакета. За это время в пакете обнаруживают критическую багу и
обновляют. Мантейнер возвращается и заливает свой пакет, не заметив
обновления. Один changelog потерян.

> Если вы имеете ввиду какие-то сторонние - то это все равно что в
> первый раз ставить. Из-за того, что лично вам это кажется нелогичным,
> вовсе не следует что во всем виноват апт или тем более рпм.
Ну вот хоть про нелогичность договорились.

>> поскольку нет никакой гарантии, что ссылки на пакеты в changelog имеют
>> в виду пакеты из архива Сизифа, а не из личного архива сборщика. При
>> этом и версии и релизы могут совпадать, то есть это вообще практически
>> бесполезная информация.
> Если версии и релизы совпадают - это ошибка упаковки.
Чего это вдруг. Я собираю пакет для себя у себя. Кто-то еще у себя для
себя. А кто-то для Сизифа. Как нам синхронизироваться, через
libastral?

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

>> Думайте шире. Пакет из Сизифа может быть переложен из этого самого
>> Сизифа в репозитарий имени Васи Пупкина. При этом запись о том, что в
>> такой то версии был поправлен такой то баг становиться вызывающе
>> неверной, так как пакет с этой версией в репозитарии Васи Пупкина
>> вообще такого бага не содержал.
> В таком случае это проблема Васи Пупкина. Предлагайте Пупкину выкинуть
> апт и рпм, потому что это инструмент плохой, а не Пупкин, который не
> предупредил своих пользователей о опасности смешивания репозитариев.
Эта опасность вам только кажется. В SuSe, как минимум ранше (а может и
теперь) в официальном репозитории лежала сборка libxine, которая при
попытке воспроизвести DVD, сообщала, что из-за лицензионных проблем
это невозможно, но если у вас в стране с этим спокойно, или вам вообще
плевать, то можно подключить сторонний репозиторий. Если его
подключить, то там лежит обычный libxine, который обновляет текущий,
плюс тащит libdvdcss, плюс еще пачку кодеков. В чем проблема. При этом
история у этих разных libxine все-таки должны быть разные. Вот вам и
привязка к репозиторию. При этом, если когда-нибудь проблемы с
лицензиями исчезнут, то при переносе сомнительной libxine в основной
репозиторий я бы хотел просто увидеть продолжение старой истории вида:
теперь с лицензиями все в порядке, поэтому мы переложили пакет из
кого-то репозитория в основной. Это полезная информация. А вот на
историю пакета в прошлом репозитории пользователям основного плевать,
поскольку ну не было у них его. Так вот и получается, что нет истории
пакета вообще, а только история пакета в репозитарии.

>>> Прошу прощения, но вы говорите о несоотвествии changelog и пакета? Это
>>> проблема конкретного сборщика.
>> Я говорю, что сборщиков может быть много. И у каждого своя история --
>> история сборки пакета в конкретный репозитарий.
> Тогда это разные пакеты просто.
Да но с одним названием из одних и тех же исходников...

>> Видимо мы не поняли друг друга. Под автоматикой я имел сервис
>> x11_autosetup, который упрямо выставлял мне неработающий драйвер. И
>> это прекрасно известно и нечего пенять на ABI, просто надо починить
>> этот сервис, чтобы он хотя бы драйвер nv проставлял.
> А если удалить драйвера nvidia (все равно они нерабочие)?
Тоже вариант. Но потом вручную проверять не обновились ли они. А так
как вышли бы новые, так автоматически и приехали бы и автоматика их бы
поставила, мечты-мечты.

>>> Намекну: зачем нужен Serial?
>> Отвечу, что затем, чтобы поднять версию.
> Вопрос второй (еще более наводящий) - зачем поднимать версию?
>
>> Спрошу: а зачем для этого пересобирать пакет?
> Ответ вытекает напрямую из ответа на второй наводящий вопрос.
Так все-таки меня больше интересует не вопрос "зачем поднимать
версию?", который простой и понятный, а вопрос "зачем пересобирать
пакет с нуля, если вся разница заключается в версии/описании/etc"

> Гм. У вас тут фундаментальное непонимание чего делает --short-circuit.
Да ничего интересного он не делает. Просто выполняет одну стадию
сборки, пропуская все остальные в надежде, что они уже выполнены.

>> Тем не менее это все равно жуткий оверхед. Представьте, что вы
>> собираете игрушку уровня doom3 -- несколько гигабайт данных. И после
>> сборки заметили, что и вас один символ в %post скрипте не правильный
>> (опечатка), сильно вам поможит --short-circuit?
> Сильно поможет. Вы специально придумываете такие примеры?
Да не поможет, потому что пакет очень долго будет архивироваться.
Вместо этого нормальный пакет мог бы содержать дополнительную
информацию в конце файла и иметь средства при необходимости заменять
только ее.

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

Re: [devel] поддержка пакетов в git

[Damir Shayhutdinov]

> Эта ситуация может быть вполне обычной, если второй репозиторий
> специально приспособлен, чтобы быть подключенным к первому. Только в
> альтах Сизиф очень не дружелюбен к сторонним репозитариям. Тогда как
> дебиан вполне дружелюбен.
В любом случае это работа мантейнеров второго репозитария.
Центральный репозитарий в данном случае Сизиф (или бранч).

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

> Я знаю, что в Сизифе все в порядке. Но этот порядок там сейчас
> поддерживается вручную. Простая ситуация: мантейнер пакета foo уезжает
> в отпуск с ноутом в деревню без инета, где вылизывает новую версию
> этого пакета. За это время в пакете обнаруживают критическую багу и
> обновляют. Мантейнер возвращается и заливает свой пакет, не заметив
> обновления. Один changelog потерян.
Это проблема мантейнера - что он потерял NMU. В новой системе при
сборке из git такое будет исключено.

>>> поскольку нет никакой гарантии, что ссылки на пакеты в changelog имеют
>>> в виду пакеты из архива Сизифа, а не из личного архива сборщика. При
>>> этом и версии и релизы могут совпадать, то есть это вообще практически
>>> бесполезная информация.
>> Если версии и релизы совпадают - это ошибка упаковки.
> Чего это вдруг. Я собираю пакет для себя у себя. Кто-то еще у себя для
> себя. А кто-то для Сизифа. Как нам синхронизироваться, через
> libastral?
Синхронизоваться надо если есть общий ресурс. Если общего ресурса нет
- синхронизация не нужна.
Общий ресурс в данном случае - версия + релиз.

Правило изменения версий и релизов пакетов в Сизифе или в
дистрибутивах Альта вам известно. Вам надо лишь обеспечить чтобы ваши
собственные релизы не пересекались

Решение: использовать те же правила, что и для бекпортов.
Как один из вариантов - делайте версию -altN.maslM.

Сложно было догадаться?

> плюс тащит libdvdcss, плюс еще пачку кодеков. В чем проблема. При этом
> история у этих разных libxine все-таки должны быть разные.
Не вижу никаких причин для вышеозвученного тезиса. Здесь у вас логика
спотыкается и хромает.
Поэтому все нижеследующие можно пропустить. Обоснуйте-ка этот тезис.

>> Тогда это разные пакеты просто.
> Да но с одним названием из одних и тех же исходников...
Это ничего не значит. Важны не только исходники апстрима, но и патчи,
ключи configure,
версии компиляторов и много чего еще. Эта информация как правило
наследуется от предыдущих сборок. Поэтому changelog тут важен.

>> А если удалить драйвера nvidia (все равно они нерабочие)?
> Тоже вариант. Но потом вручную проверять не обновились ли они. А так
> как вышли бы новые, так автоматически и приехали бы и автоматика их бы
> поставила, мечты-мечты.
Напильник в руки, патчи в багзиллу.

>>>> Намекну: зачем нужен Serial?
>>> Отвечу, что затем, чтобы поднять версию.
>> Вопрос второй (еще более наводящий) - зачем поднимать версию?
Ответьте пожалуйста на этот вопрос.

>>> Спрошу: а зачем для этого пересобирать пакет?
>> Ответ вытекает напрямую из ответа на второй наводящий вопрос.
> Так все-таки меня больше интересует не вопрос "зачем поднимать
> версию?", который простой и понятный
Озвучьте пожалуйста простой и понятный ответ.

>, а вопрос "зачем пересобирать
> пакет с нуля, если вся разница заключается в версии/описании/etc"
Если вы например в скриптах post/postun исправили "опечатку", это
может повлечь изменение зависимостей пакета. То есть как минимум после
каждого изменения скриптов надо провести повторный поиск зависимостей.

>> Гм. У вас тут фундаментальное непонимание чего делает --short-circuit.
> Да ничего интересного он не делает. Просто выполняет одну стадию
> сборки, пропуская все остальные в надежде, что они уже выполнены.
При условии что они уже выполнены. Если вы меняете что-нибудь в спеке
- это одно. А если в исходниках - это другое. В таком случае условие
"они уже выполнены" не соблюдаются.

> Да не поможет, потому что пакет очень долго будет архивироваться.
> Вместо этого нормальный пакет мог бы содержать дополнительную
> информацию в конце файла и иметь средства при необходимости заменять
> только ее.
Формат пакетов rpm открытый. Если бы такие возможности были
кому-нибудь нужны - давно бы уже написали программу для этого. Ищите.
Если нет - значит это нужно только вам.

Пока получается, что ради того, чтобы "0.0001% пакетов не очень долго
архивировался в случае, если допущена ошибка в дополнительной
информации (ну допустим вероятность ошибки около 50%)", вы предлагаете
решение, которое как минимум дольше и разрабатывать, и поддерживать.
Если вам это так интересно и нужно - предлагаю взять в руки librpm и
написать требуемую программу. 0.0001% мантейнеров в 50% случаев вам
скажут большое спасибо.

Re: [devel] поддержка пакетов в git

[Dmitriy M. Maslennikov]

25 сентября 2008 г. 14:50 пользователь Damir Shayhutdinov
<damir@altlinux.org> написал:
> В любом случае это работа мантейнеров второго репозитария.
> Центральный репозитарий в данном случае Сизиф (или бранч).
>
> Лично я не вижу препятствий, из-за которых мантейнеры второго
> репозитария не могли бы поддерживать
> возможность обновления с их репозитария до Сизифа например по тем же
> правилам, по которым поддерживаются
> пакеты в бранчах.
В целом да, только я скорее имел в виду не возможность обновления до
Сизифа, а именно репозиторий, как довесок к Сизифу, использующийся с
ним совместно.

> Это проблема мантейнера - что он потерял NMU. В новой системе при
> сборке из git такое будет исключено.
Посмотрим :)

>> Чего это вдруг. Я собираю пакет для себя у себя. Кто-то еще у себя для
>> себя. А кто-то для Сизифа. Как нам синхронизироваться, через
>> libastral?
> Синхронизоваться надо если есть общий ресурс. Если общего ресурса нет
> - синхронизация не нужна.
> Общий ресурс в данном случае - версия + релиз.
>
> Правило изменения версий и релизов пакетов в Сизифе или в
> дистрибутивах Альта вам известно. Вам надо лишь обеспечить чтобы ваши
> собственные релизы не пересекались
>
> Решение: использовать те же правила, что и для бекпортов.
> Как один из вариантов - делайте версию -altN.maslM.
Есть задача: заменить один из пакетов в Сизифе. Как этого добиться не
понимаю, разве что с помощью serial, но что если в Сизифе сериал
поднимется выше моего?

>> плюс тащит libdvdcss, плюс еще пачку кодеков. В чем проблема. При этом
>> история у этих разных libxine все-таки должны быть разные.
> Не вижу никаких причин для вышеозвученного тезиса. Здесь у вас логика
> спотыкается и хромает.
> Поэтому все нижеследующие можно пропустить. Обоснуйте-ка этот тезис.
Ну вышесказанное относилось к гипотетической возможности
перекладывания пакетов между репозитариями вообще без пересборки.

>>>>> Намекну: зачем нужен Serial?
>>>> Отвечу, что затем, чтобы поднять версию.
>>> Вопрос второй (еще более наводящий) - зачем поднимать версию?
> Ответьте пожалуйста на этот вопрос.
Версию пакета поднимать нужно затем, что apt обновляет rpm пакеты
основываясь исключительно на их версиях. Я утверждаю, что полезен был
бы механизм выкладывания на сервере более старой версии, после того,
как там уже была новая. При этом пользователей, которые не успели
обновиться такое затронуть не должно, тем которые уже обновились apt
должен предлагать откатить версию. При выкладывании более старой
версии в changelog обязательно должна излагаться причина такого отката
версии. Пересборку считаю излишней.

>>, а вопрос "зачем пересобирать
>> пакет с нуля, если вся разница заключается в версии/описании/etc"
> Если вы например в скриптах post/postun исправили "опечатку", это
> может повлечь изменение зависимостей пакета. То есть как минимум после
> каждого изменения скриптов надо провести повторный поиск зависимостей.
Отлично, пусть произойдет повторный поиск зависимостей по скриптам,
зачем пересобирать?

>>> Гм. У вас тут фундаментальное непонимание чего делает --short-circuit.
>> Да ничего интересного он не делает. Просто выполняет одну стадию
>> сборки, пропуская все остальные в надежде, что они уже выполнены.
> При условии что они уже выполнены. Если вы меняете что-нибудь в спеке
> - это одно. А если в исходниках - это другое. В таком случае условие
> "они уже выполнены" не соблюдаются.
Это вы должны вызывать rpmbuild с --short-circuit "при условии"
выполнения предыдущих стадий, а вот он запускается "в надежде" на это.
Кстати, я частенько менял исходники, а затем вызывал

$rpmbuild -bc --short-circuit

и мне плевать, что формально у меня -bi уже не выполнено. Зато после
починки сборки я могу одним движением сделать diff.

> Пока получается, что ради того, чтобы "0.0001% пакетов не очень долго
> архивировался в случае, если допущена ошибка в дополнительной
> информации (ну допустим вероятность ошибки около 50%)", вы предлагаете
> решение, которое как минимум дольше и разрабатывать, и поддерживать.
> Если вам это так интересно и нужно - предлагаю взять в руки librpm и
> написать требуемую программу. 0.0001% мантейнеров в 50% случаев вам
> скажут большое спасибо.
Может быть вы и правы, но у меня другая оценка процентных соотношений.
Наверное дело в том, что я больше не собираю пакеты, а разрабатываю их
с нуля. Собираю соответственно в основном свои пакеты для того, чтобы
отдать их на потестить. Качество самого пакета при этом не критично
(до стадии выкладывания пользователю), так вот меня пересборка rpm на
каждый чих уже совсем не радует (и давно). Меня достает, что каждый
раз, когда я поправил мелкий баг (до 10-15 раз за день) собрал пакет,
я вдруг осознаю, что люди его через apt не получат, поскольку
версию-то я сменить забыл, а потом вдруг окажется, что забыл вписать
changelog, вот так и пересобираешь все по сто раз.

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

Re: [devel] поддержка пакетов в git

[Damir Shayhutdinov]

>> Лично я не вижу препятствий, из-за которых мантейнеры второго
>> репозитария не могли бы поддерживать
>> возможность обновления с их репозитария до Сизифа например по тем же
>> правилам, по которым поддерживаются
>> пакеты в бранчах.
> В целом да, только я скорее имел в виду не возможность обновления до
> Сизифа, а именно репозиторий, как довесок к Сизифу, использующийся с
> ним совместно.
Гм. А тут тогда в чем проблема? Если это пакеты, которых в сизифе нет
- пересечений быть не должно.

>> Решение: использовать те же правила, что и для бекпортов.
>> Как один из вариантов - делайте версию -altN.maslM.
> Есть задача: заменить один из пакетов в Сизифе. Как этого добиться не
> понимаю, разве что с помощью serial, но что если в Сизифе сериал
> поднимется выше моего?
У вас задача неполная. "Заменить один из пакетов в Сизифе" может на
практике означать несколько вариантов, как то - замена определенной
сборки пакета (release), замена определенной версии (на ту же или
большую), замена "навсегда".

Замена определенной сборки пакета делается просто. Допустим это была
сборка version-alt1. Делаете релиз alt1.masl1 - и все в порядке. При
этом если в Сизифе появится сборка с alt2 - то она перекроет вашу
местную сборку.

Замена определенной версии делается примерно также. То есть вы хотите
чтобы пакет из Сизифа версии M был заменен на ваш, а версии M+1 -
брался из Сизифа. Тогда делаете релиз равный alt999.masl1.

Замена "навсегда" - делаете пакет с Serial: сто-пятьсот-тысяч-мульенов.

Мне кажется что ваша позиция "апт и рпм плохие, а я самый умный" в
данном случае мешает вам находить эти очевиднейшие решения.

> Ну вышесказанное относилось к гипотетической возможности
> перекладывания пакетов между репозитариями вообще без пересборки.
Перечитайте контекст.


>>>>>> Намекну: зачем нужен Serial?
>>>>> Отвечу, что затем, чтобы поднять версию.
>>>> Вопрос второй (еще более наводящий) - зачем поднимать версию?
>> Ответьте пожалуйста на этот вопрос.
> Версию пакета поднимать нужно затем, что apt обновляет rpm пакеты
> основываясь исключительно на их версиях.
Ключевое слово тут - _обновляет_.
Вспоминаем изначальный вопрос: "Не понимаю, как пакеты установленные у
пользователя мешают нормальной
работе репозитория". Ответ такой - у пользователя версии установленные
могут быть выше того, что лежит в репозитарии, и поэтому эти пакеты не
будут обновлены (то есть заменены из репозитария).
Таким образом, "откат версий" централизованно можно сделать только с
изменением Serial. А изменение Serial:Version-Release - это новая
строчка в changelog и новая сборка пакета.

Отмечу, что нецентрализованный откат версий может делаться как с
помощью прямого указания старой версии (apt-get install
package=version), так и с помощью apt_preferences.

> Я утверждаю, что полезен был
> бы механизм выкладывания на сервере более старой версии, после того,
> как там уже была новая. При этом пользователей, которые не успели
> обновиться такое затронуть не должно, тем которые уже обновились apt
> должен предлагать откатить версию.
Это сделает работу апта бессмысленной, если он будет автоматически
даунгрейдить пакеты если их нет в репозитарии. Ваше решение не
выдерживает никакой критики. Думайте дальше.

> При выкладывании более старой
> версии в changelog обязательно должна излагаться причина такого отката
> версии. Пересборку считаю излишней.
Я не могу спорить с человеком, который считает пересборку излишней при
изменении версии пакета и добавлении записи в changelog. Вы такой
хакер что можете предусмотреть все последствия этих изменений? Тогда
пишите программу для этого. Я лично не берусь предусмотреть всех
последствий, для чего делаю контрольную пересборку начисто.

>> Если вы например в скриптах post/postun исправили "опечатку", это
>> может повлечь изменение зависимостей пакета. То есть как минимум после
>> каждого изменения скриптов надо провести повторный поиск зависимостей.
> Отлично, пусть произойдет повторный поиск зависимостей по скриптам,
> зачем пересобирать?
rpm -bb --short-circuit делает то что надо в этом случае. Производит
повторный поиск зависимостей.

> Это вы должны вызывать rpmbuild с --short-circuit "при условии"
> выполнения предыдущих стадий, а вот он запускается "в надежде" на это.
> Кстати, я частенько менял исходники, а затем вызывал
>
> $rpmbuild -bc --short-circuit
>
> и мне плевать, что формально у меня -bi уже не выполнено. Зато после
> починки сборки я могу одним движением сделать diff.
После такого признания хочется посмотреть список ваших пакетов, чтобы
никогда их не ставить в систему. Сборки, которые не соответствуют
.src.rpm - нужны только вам.
Я всегда делаю контрольную "чистовую" пересборку после завершения
хаков с --short-circuit. И тестирую именно ее. Да, это дольше. Зато я
не трачу времени на поиск багов, которые я могу внести ковырясь с
--short-circuit.

> Наверное дело в том, что я больше не собираю пакеты, а разрабатываю их
> с нуля. Собираю соответственно в основном свои пакеты для того, чтобы
> отдать их на потестить. Качество самого пакета при этом не критично
> (до стадии выкладывания пользователю), так вот меня пересборка rpm на
> каждый чих уже совсем не радует (и давно). Меня достает, что каждый
> раз, когда я поправил мелкий баг (до 10-15 раз за день) собрал пакет,
> я вдруг осознаю, что люди его через apt не получат, поскольку
> версию-то я сменить забыл, а потом вдруг окажется, что забыл вписать
> changelog, вот так и пересобираешь все по сто раз.
Все ясно.

У меня никогда не бывает что я "не вписал changelog" - просто на входе
в хешер sisyphus_check такой пакет не пропустит. Да и забыть сменить
версию тоже сложно - обычно тарбол апстримный разворачивается в
%name-%version, а если %version не совпадает, то пакет даже не начнет
собираться.

Очевидно, что вы ваши сборки через sisyphus_check не гоняете. Советую
приучиться это делать - тогда пересобирать по сто раз не придется.
(это безотносительно к рекомендации пользоваться hasher).

Re: [devel] поддержка пакетов в git

[Timur Batyrshin]

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

On Thu, 25 Sep 2008 16:13:23 +0400
Damir Shayhutdinov wrote:

> Замена определенной версии делается примерно также. То есть вы хотите
> чтобы пакет из Сизифа версии M был заменен на ваш, а версии M+1 -
> брался из Сизифа. Тогда делаете релиз равный alt999.masl1.

Можно, наверное и просто masl1 , т.к. masl > alt ?

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

Re: [devel] поддержка пакетов в git

[Damir Shayhutdinov]

>> Замена определенной версии делается примерно также. То есть вы хотите
>> чтобы пакет из Сизифа версии M был заменен на ваш, а версии M+1 -
>> брался из Сизифа. Тогда делаете релиз равный alt999.masl1.
>
> Можно, наверное и просто masl1 , т.к. masl > alt ?

В принципе да, конечно, но если хочется указать, что пакет именно для
альта - то лучше alt оставлять.
Особенно если есть сборки masl не для альта.

Re: [devel] поддержка пакетов в git

[Dmitriy M. Maslennikov]

25 сентября 2008 г. 16:13 пользователь Damir Shayhutdinov
<damir@altlinux.org> написал:
>> В целом да, только я скорее имел в виду не возможность обновления до
>> Сизифа, а именно репозиторий, как довесок к Сизифу, использующийся с
>> ним совместно.
> Гм. А тут тогда в чем проблема? Если это пакеты, которых в сизифе нет
> - пересечений быть не должно.
Я про пересечения пример с libxine приводил.

> У вас задача неполная. "Заменить один из пакетов в Сизифе" может на
> практике означать несколько вариантов, как то - замена определенной
> сборки пакета (release), замена определенной версии (на ту же или
> большую), замена "навсегда".
>
> Замена определенной сборки пакета делается просто. Допустим это была
> сборка version-alt1. Делаете релиз alt1.masl1 - и все в порядке. При
> этом если в Сизифе появится сборка с alt2 - то она перекроет вашу
> местную сборку.
>
> Замена определенной версии делается примерно также. То есть вы хотите
> чтобы пакет из Сизифа версии M был заменен на ваш, а версии M+1 -
> брался из Сизифа. Тогда делаете релиз равный alt999.masl1.
>
> Замена "навсегда" - делаете пакет с Serial: сто-пятьсот-тысяч-мульенов.
>
> Мне кажется что ваша позиция "апт и рпм плохие, а я самый умный" в
> данном случае мешает вам находить эти очевиднейшие решения.
Все вышеописанное я делал многократно. Просто у вас задач таких не
было. Например: подменить пакет в Сизифе с помощью стороннего
репозитария, а потом когда с тем пакетом все разногласия будут улажены
убрать свой. То есть я сам решаю, когда это случиться.

> Ключевое слово тут - _обновляет_.
> Вспоминаем изначальный вопрос: "Не понимаю, как пакеты установленные у
> пользователя мешают нормальной
> работе репозитория". Ответ такой - у пользователя версии установленные
> могут быть выше того, что лежит в репозитарии, и поэтому эти пакеты не
> будут обновлены (то есть заменены из репозитария).
> Таким образом, "откат версий" централизованно можно сделать только с
> изменением Serial. А изменение Serial:Version-Release - это новая
> строчка в changelog и новая сборка пакета.
Это только потому, что apt кривой. Точнее не кривой даже, а просто
когда задумывался, то в нем это не предусмотрели. Не вижу проблемы в
том, чтобы пакеты обновлялись не по rpm-версии, а по внутренней версии
apt. Тогда можно было бы выкладывать пакеты в любой последовательности
с гарантией, что пользователь получит последнюю выложенную версию. И
костыль с serial станет не нужным вообще.

> Отмечу, что нецентрализованный откат версий может делаться как с
> помощью прямого указания старой версии (apt-get install
> package=version), так и с помощью apt_preferences.
Нецентрализованный не интересен. Не надо напрягать пользователя, это
мы для него, а не он для нас.

>> Я утверждаю, что полезен был
>> бы механизм выкладывания на сервере более старой версии, после того,
>> как там уже была новая. При этом пользователей, которые не успели
>> обновиться такое затронуть не должно, тем которые уже обновились apt
>> должен предлагать откатить версию.
> Это сделает работу апта бессмысленной, если он будет автоматически
> даунгрейдить пакеты если их нет в репозитарии. Ваше решение не
> выдерживает никакой критики. Думайте дальше.
С чего он будет даунгрейдить пакеты? Из чего это следует. Он будет
обеспечивать наличие у пользователя версий пакетов выложенных
последними. Сами версии значения не имеют. Раз мантейнер выложил
пакет, значит было надо.

> Я не могу спорить с человеком, который считает пересборку излишней при
> изменении версии пакета и добавлении записи в changelog. Вы такой
> хакер что можете предусмотреть все последствия этих изменений? Тогда
> пишите программу для этого. Я лично не берусь предусмотреть всех
> последствий, для чего делаю контрольную пересборку начисто.
Я не всегда собираю пакет для того, чтобы отдать его конечному
пользователю. Я понимаю необходимость такого контроля при
выкладывании, скажем, в Сизиф, но я часто собираю пакет для себя на
потестить, или чтобы иметь возможность его дать тестеру и т. п. Баги в
таких пакетах совсем не так критичны, как легкость их создания. Я
вообще не желаю в этом случае поднимать версию пакета, так как
незачем, иначе версии взлетять до тысяч... Я же их не публикую.
Представьте, что вам перед каждой компиляцией программы надо где-то в
файле обязательно поднимать версию иначе версия не собирается, но не
сразу, а ближе к финалу. Это кошмар! Публичные же релизы достаточно
редки, их можно и повылизывать и тут всякие барьеры вида sisyphu_check
repocop и прочее очень полезны. Но вот отсутствие инструментария для
быстрых изменений...

>> Отлично, пусть произойдет повторный поиск зависимостей по скриптам,
>> зачем пересобирать?
> rpm -bb --short-circuit делает то что надо в этом случае. Производит
> повторный поиск зависимостей.
Кроме этого он заново начнет архивировать файлы, а ведь мне надо было
только информацию о пакете поправить.

> После такого признания хочется посмотреть список ваших пакетов, чтобы
> никогда их не ставить в систему. Сборки, которые не соответствуют
> .src.rpm - нужны только вам.
Вот именно. Я такие и не выкладываю, но это сильно ускоряет процесс
установки. После того, как он завершен, можно спокойно сделать пакет
начисто. И так делаю не только я -- это точно.

> Я всегда делаю контрольную "чистовую" пересборку после завершения
> хаков с --short-circuit. И тестирую именно ее. Да, это дольше. Зато я
> не трачу времени на поиск багов, которые я могу внести ковырясь с
> --short-circuit.
Я тоже так делаю, и что?

> Все ясно.
Ну наконец-то!

> У меня никогда не бывает что я "не вписал changelog" - просто на входе
> в хешер sisyphus_check такой пакет не пропустит. Да и забыть сменить
> версию тоже сложно - обычно тарбол апстримный разворачивается в
> %name-%version, а если %version не совпадает, то пакет даже не начнет
> собираться.
Вот-вот, ведешь разработку, радостно закоммитил мелкие изменения,
запускаешь сборку и тут эта пакость (но ее я уже отключаю автоматом).
Эта автоматика нужна во время финальной сборки, перед публикацией, не
во время активной разработки.

> Очевидно, что вы ваши сборки через sisyphus_check не гоняете. Советую
> приучиться это делать - тогда пересобирать по сто раз не придется.
> (это безотносительно к рекомендации пользоваться hasher).
К сожалению, sisyphus_check не проверяет поднял ли я версию пакета...
А потом у тестеров пакет не обновляется.

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

Re: [devel] поддержка пакетов в git

[Timur Batyrshin]

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

On Thu, 25 Sep 2008 18:29:42 +0400
Dmitriy M. Maslennikov wrote:

> Это только потому, что apt кривой. Точнее не кривой даже, а просто
> когда задумывался, то в нем это не предусмотрели. Не вижу проблемы в
> том, чтобы пакеты обновлялись не по rpm-версии, а по внутренней версии
> apt. Тогда можно было бы выкладывать пакеты в любой последовательности
> с гарантией, что пользователь получит последнюю выложенную версию. И
> костыль с serial станет не нужным вообще.

Причем тут "внутренняя версия apt"?
Пакеты в любом случае устанавливает не apt, а rpm.

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

Re: [devel] поддержка пакетов в git

[Dmitriy M. Maslennikov]

25 сентября 2008 г. 18:43 пользователь Timur Batyrshin
<batyrshin@ieml.ru> написал:
> Причем тут "внутренняя версия apt"?
> Пакеты в любом случае устанавливает не apt, а rpm.
А rpm прекрасно пакеты любых версий устанавливает. И старые и новые.
Так что тут проблема в apt.

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

Re: [devel] поддержка пакетов в git

[Damir Shayhutdinov]

> <batyrshin@ieml.ru> написал:
>> Причем тут "внутренняя версия apt"?
>> Пакеты в любом случае устанавливает не apt, а rpm.
> А rpm прекрасно пакеты любых версий устанавливает. И старые и новые.
> Так что тут проблема в apt.
apt тоже прекрасно устанавливает.

Разница в том, что апт поддерживает операцию dist-upgrade, а rpm - нет.

Re: [devel] поддержка пакетов в git

[Alexey I. Froloff]

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

* Dmitriy M. Maslennikov <maslennikovdm@> [080925 19:26]:
> > Причем тут "внутренняя версия apt"?
> > Пакеты в любом случае устанавливает не apt, а rpm.
> А rpm прекрасно пакеты любых версий устанавливает. И старые и новые.
> Так что тут проблема в apt.
А у меня apt тоже "прекрасно пакеты любых версий устанавливает".
Так что "проблема" у кого-то другого...

-- 
Regards,
Sir Raorn.

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

Re: [devel] поддержка пакетов в git

[Dmitriy M. Maslennikov]

25 сентября 2008 г. 21:35 пользователь Alexey I. Froloff
<raorn@altlinux.ru> написал:
>> А rpm прекрасно пакеты любых версий устанавливает. И старые и новые.
>> Так что тут проблема в apt.
> А у меня apt тоже "прекрасно пакеты любых версий устанавливает".
> Так что "проблема" у кого-то другого...
Вы или намеренно выдираете контекст или не читаете тред целиком.

В данном случае велась речь про то, что apt не умеет обновлять пакеты
до последних выложенных, а только до последних версий, в смысле rpm. И
у него вообще нет понятия выкладывания пакета, как и нет отслеживания
изменений в репозитарии. У него есть только состояние, которое
генерируется genbasedir и все. По этой причине нельзя при update
скачать толко изменения, а приходиться качать базы целиком.

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

Re: [devel] поддержка пакетов в git

[Alexey I. Froloff]

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

* Dmitriy M. Maslennikov <maslennikovdm@> [080926 11:01]:
> В данном случае велась речь про то, что apt не умеет обновлять пакеты
> до последних выложенных, а только до последних версий, в смысле rpm.
Вы не умеете пользоваться apt.  Не стучите, пожалуйста, ложкой.

-- 
Regards,
Sir Raorn.

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

Re: [devel] поддержка пакетов в git

[Led]

On Thursday 25 September 2008 17:29:42 Dmitriy M. Maslennikov wrote:
> Все вышеописанное я делал многократно. Просто у вас задач таких не
> было. Например: подменить пакет в Сизифе с помощью стороннего
> репозитария, а потом когда с тем пакетом все разногласия будут улажены
> убрать свой. То есть я сам решаю, когда это случиться.

Я постоянно так делаю. В мой личный репозитарий я кладу пакет с релизом altX.1 
и, после установки, ставлю его на Hold до момента, "когда с тем пакетом все 
разногласия будут улажены" и убираю из Hold "я сам решаю, когда это 
случиться".

-- 
Led

Re: [devel] поддержка пакетов в git

[Dmitriy M. Maslennikov]

25 сентября 2008 г. 18:51 пользователь Led <ledest@gmail.com> написал:
> Я постоянно так делаю. В мой личный репозитарий я кладу пакет с релизом altX.1
> и, после установки, ставлю его на Hold до момента, "когда с тем пакетом все
> разногласия будут улажены" и убираю из Hold "я сам решаю, когда это
> случиться".
Для себя каждый может.

А теперь представьте что у вас куча клиентов, и они заплатили вам за
то, чтобы вы решали некоторые проблемы Сизифа. Ваша задача быстро
реагировать на проблему выкладыванием пакетов (при этом до разрешения
проблем вы продолжаете сопровождение/обновление пакетов) в свой
репозиторий, который у них подключен. Затем, чтобы весь Сизиф не
переехал к вам, вы по мере сил помогаете/убеждаете/заставляете
мантейнеров принимать исправления, после чего спокойно удаляете
ставшую ненужной подмену. Так вот никакие сериалы/релизы вам здесь не
помогут. При этом разработать аналог apt, который прекрасно бы
справлялся со всеми этими и другими задачами вполне реально, только
некому. Из чего я и утверждаю, что apt - примитивный (даже убогий)
инструмент прошлого, который не справляется с реальными задачами,
которые появились с ростом популярности Linux. При этом я не ругаю
разработчиков apt, просто в то время, когда они его разрабатывали
таких задач не стояло и он справлялся, а предугадать такое сложно. Тем
не менее модернизацией apt'а никто не занимается.

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

Re: [devel] поддержка пакетов в git

[Damir Shayhutdinov]

> Для себя каждый может.
>
> А теперь представьте что у вас куча клиентов, и они заплатили вам за
> то, чтобы вы решали некоторые проблемы Сизифа. Ваша задача быстро
> реагировать на проблему выкладыванием пакетов (при этом до разрешения
> проблем вы продолжаете сопровождение/обновление пакетов) в свой
> репозиторий, который у них подключен. Затем, чтобы весь Сизиф не
> переехал к вам, вы по мере сил помогаете/убеждаете/заставляете
> мантейнеров принимать исправления, после чего спокойно удаляете
> ставшую ненужной подмену. Так вот никакие сериалы/релизы вам здесь не
> помогут.
Это ложь. Пункт 1 или 2 из соглашений о наименовании, которые я ранее упоминал.

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

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

Re: [devel] поддержка пакетов в git

[Dmitriy M. Maslennikov]

25 сентября 2008 г. 19:36 пользователь Damir Shayhutdinov
<damir@altlinux.org> написал:
>> Для себя каждый может.
>>
>> А теперь представьте что у вас куча клиентов, и они заплатили вам за
>> то, чтобы вы решали некоторые проблемы Сизифа. Ваша задача быстро
>> реагировать на проблему выкладыванием пакетов (при этом до разрешения
>> проблем вы продолжаете сопровождение/обновление пакетов) в свой
>> репозиторий, который у них подключен. Затем, чтобы весь Сизиф не
>> переехал к вам, вы по мере сил помогаете/убеждаете/заставляете
>> мантейнеров принимать исправления, после чего спокойно удаляете
>> ставшую ненужной подмену. Так вот никакие сериалы/релизы вам здесь не
>> помогут.
> Это ложь. Пункт 1 или 2 из соглашений о наименовании, которые я ранее упоминал.
Нет, не подходят. Дело в том, что пакет в Сизифе может поменять и
версию и релиз в любой момент. И это процесс неконтролируем и
непредсказуем. И ваши пользователи получат пакет снова из Сизифа и
снова с багом/недоработкой.

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

Re: [devel] поддержка пакетов в git

[Dmitriy M. Maslennikov]

25 сентября 2008 г. 19:39 пользователь Led <ledest@gmail.com> написал:
> Занимаются: в gentoo - "модернизированный apt", похоже, что вам - туда:)
К сожалению или к счастью, но мне платят за Alt. И остаюсь.

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

Re: [devel] поддержка пакетов в git

[Damir Shayhutdinov]

>>> В целом да, только я скорее имел в виду не возможность обновления до
>>> Сизифа, а именно репозиторий, как довесок к Сизифу, использующийся с
>>> ним совместно.
>> Гм. А тут тогда в чем проблема? Если это пакеты, которых в сизифе нет
>> - пересечений быть не должно.
> Я про пересечения пример с libxine приводил.
Второй или третий вариант.

>> Мне кажется что ваша позиция "апт и рпм плохие, а я самый умный" в
>> данном случае мешает вам находить эти очевиднейшие решения.
> Все вышеописанное я делал многократно. Просто у вас задач таких не
> было. Например: подменить пакет в Сизифе с помощью стороннего
> репозитария, а потом когда с тем пакетом все разногласия будут улажены
> убрать свой. То есть я сам решаю, когда это случиться.
Вы вкурсе, что если вы в репозитарии уберете пакет, он магическим
образом у пользователей, которые его поставили, не исчезнет?

> Это только потому, что apt кривой. Точнее не кривой даже, а просто
> когда задумывался, то в нем это не предусмотрели. Не вижу проблемы в
> том, чтобы пакеты обновлялись не по rpm-версии, а по внутренней версии
> apt. Тогда можно было бы выкладывать пакеты в любой последовательности
> с гарантией, что пользователь получит последнюю выложенную версию. И
> костыль с serial станет не нужным вообще.
Опишите что это за "внутренняя версия apt", как она создается, для
чего и что делать если делается апгрейд
с бранча на сизиф например? При том что в бранче бэкпорты как правило
базируются на пакете в Сизифе, и как следствие, имеют более позднюю
дату сборки?


> С чего он будет даунгрейдить пакеты? Из чего это следует. Он будет
> обеспечивать наличие у пользователя версий пакетов выложенных
> последними. Сами версии значения не имеют. Раз мантейнер выложил
> пакет, значит было надо.
С вышеописанного (про внутреннюю версию апта).

>> Я не могу спорить с человеком, который считает пересборку излишней при
>> изменении версии пакета и добавлении записи в changelog. Вы такой
>> хакер что можете предусмотреть все последствия этих изменений? Тогда
>> пишите программу для этого. Я лично не берусь предусмотреть всех
>> последствий, для чего делаю контрольную пересборку начисто.
> Я не всегда собираю пакет для того, чтобы отдать его конечному
> пользователю. Я понимаю необходимость такого контроля при
> выкладывании, скажем, в Сизиф, но я часто собираю пакет для себя на
> потестить, или чтобы иметь возможность его дать тестеру и т. п. Баги в
> таких пакетах совсем не так критичны, как легкость их создания.
Очевидно, слова "воспроизводимость" для вас пустой звук. Вы тестируете
бинарного коня в вакууме, собранного неизвестно из чего? Гм, ну тут я
ничего сказать не могу. Жалко ваших тестировщиков.

> Я
> вообще не желаю в этом случае поднимать версию пакета, так как
> незачем, иначе версии взлетять до тысяч... Я же их не публикую.
git/gear не пробовали? Отличное решение для совместной разработки. А в
вашем случае это именно совместная разработка, а не ведение
репозитария. Сценарий взаимодействия другой.

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

> Это кошмар! Публичные же релизы достаточно
> редки, их можно и повылизывать и тут всякие барьеры вида sisyphu_check
> repocop и прочее очень полезны. Но вот отсутствие инструментария для
> быстрых изменений...
sisyphus_check полезен всегда. А инструментарий отсутствует, на мой
взгляд, по стандартной причине опенсорса. Те, кому нужен
инструментарий, по очевидным причинам не могут его написать. А те кто
могут написать, по не менее очевидным причинам он не нужен.

>>> Отлично, пусть произойдет повторный поиск зависимостей по скриптам,
>>> зачем пересобирать?
>> rpm -bb --short-circuit делает то что надо в этом случае. Производит
>> повторный поиск зависимостей.
> Кроме этого он заново начнет архивировать файлы, а ведь мне надо было
> только информацию о пакете поправить.
Только такой способ позволяет удостовериться, что пакет получился
целостным, а не хакнутым руками с конечным радиусом кривизны через
конечного радиуса кривизны программу для правки информации о пакете.
Например, информация о версии и релизе пакета может быть использована
также в Requires/Provides пакетов и подпакетов. И если ее менять, это
надо делать везде, чтобы было целостное изменение.

> Вот именно. Я такие и не выкладываю, но это сильно ускоряет процесс
> установки. После того, как он завершен, можно спокойно сделать пакет
> начисто. И так делаю не только я -- это точно.
Процесс установки чего? Фразу не понял.

>> Я всегда делаю контрольную "чистовую" пересборку после завершения
> Я тоже так делаю, и что?
Тогда я не вижу с чего вы в одном случае так делаете, а в другом вам
почему-то этого делать не хочется.

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

> Эта автоматика нужна во время финальной сборки, перед публикацией, не
> во время активной разработки.
А потом вы жалуетесь что автоматика срабатывает слишком поздно, когда
пакет уже собран. Надо определяться, чего именно хочется. Хочется
правильной сборки - не отключайте проверку.

> К сожалению, sisyphus_check не проверяет поднял ли я версию пакета...
> А потом у тестеров пакет не обновляется.
да все обновляется, через rpm. Но вы ж должны понимать, что без смены
релиза результат вашего дистрибутива можно ставить только вашим
тестерам и более никому. Пока это между вами и тестером - пользуйтесь
чем угодно. Но в люди выходить без смены релиза - засмеют.

Re: [devel] поддержка пакетов в git

[Dmitriy M. Maslennikov]

25 сентября 2008 г. 19:31 пользователь Damir Shayhutdinov
<damir@altlinux.org> написал:
> Вы вкурсе, что если вы в репозитарии уберете пакет, он магическим
> образом у пользователей, которые его поставили, не исчезнет?
Конечно.

> Опишите что это за "внутренняя версия apt", как она создается, для
> чего и что делать если делается апгрейд
> с бранча на сизиф например? При том что в бранче бэкпорты как правило
> базируются на пакете в Сизифе, и как следствие, имеют более позднюю
> дату сборки?
Запросто. Я уже описывал это в этом треде, но, наверное он слишком велик.

Так вот перебирать кучу пакетов с помощью genbasedir - очень
неоптимальное действие. Его надо заменить на процедуру добавления
пакета.

При добавлении пакета foo, если такого еще не было ему присваивается
версия 1, если уже был, то она поднимается. Эта внутренняя версия к
версии rpm она отношения не имеет. При этом если пакет у нас уже был,
то для замены его новой версией (не в смысле rpm, а в смысле
внутренней версии) обязательно должен быть описано изменение, которое
производит это выкладывание. Из этих описаний формируется changelog.

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

Если пакет был найден в нескольких, то в рассмотрение берется самый
приоритетный, а остальные игнорируются.

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

>> С чего он будет даунгрейдить пакеты? Из чего это следует. Он будет
>> обеспечивать наличие у пользователя версий пакетов выложенных
>> последними. Сами версии значения не имеют. Раз мантейнер выложил
>> пакет, значит было надо.
> С вышеописанного (про внутреннюю версию апта).
Как видим, apt будет даунгрейдить пакет, только если он имеется в
более приоритетном репозитарии. Раз уж вы его поставили как более
приоритетный, то знали, что он будет управлять вашими пакетами. Если
вам необходима большая версия -- подключаем репозитарий, в котором она
есть как более приоритетный. Пакетам установленным вручную (не из
репозитария), так же назначается приоритет. Полезно уметь выводить
список таких пакетов, как и вообще списки пакетов, поставленных из
того или иного репозитария.

>> Я не всегда собираю пакет для того, чтобы отдать его конечному
>> пользователю. Я понимаю необходимость такого контроля при
>> выкладывании, скажем, в Сизиф, но я часто собираю пакет для себя на
>> потестить, или чтобы иметь возможность его дать тестеру и т. п. Баги в
>> таких пакетах совсем не так критичны, как легкость их создания.
> Очевидно, слова "воспроизводимость" для вас пустой звук. Вы тестируете
> бинарного коня в вакууме, собранного неизвестно из чего? Гм, ну тут я
> ничего сказать не могу. Жалко ваших тестировщиков.
На самом деле в 99% я бываю прав. Потери времени на оставшийся процент
многократно компенсируются гигантской экономией времени на
сборку/пересборку.

> git/gear не пробовали? Отличное решение для совместной разработки. А в
> вашем случае это именно совместная разработка, а не ведение
> репозитария. Сценарий взаимодействия другой.
Только ими и пользуюсь. Без них вообще бы труба. С чего вы все время
делаете вывод, что я не знаю ваш инструментарий?
Проблема в том, что часто надо отдать именно бинарную сборку. И кучу
файлов с ней. И если она не удачна, то дать возможность все удалить.
Поэтому надо собирать rpm, и на это тратиться много сил и времени,
хотя чаще всего пакет собирается только, чтобы продемонстрировать
мелкое изменение людям внутри компании, которое больше никуда не
пойдет. При таких задачах rpm очень сильно умничает. А вот apt тупит.

>> Вот именно. Я такие и не выкладываю, но это сильно ускоряет процесс
>> установки. После того, как он завершен, можно спокойно сделать пакет
>> начисто. И так делаю не только я -- это точно.
> Процесс установки чего? Фразу не понял.
Фразу надо читать как "просесс разработки". Опечатался я.

>>> Я всегда делаю контрольную "чистовую" пересборку после завершения
>> Я тоже так делаю, и что?
> Тогда я не вижу с чего вы в одном случае так делаете, а в другом вам
> почему-то этого делать не хочется.
Только потому, что один пакет идет пользователю, а второй собирается
для себя на посмотреть, через пять минут удаляется и продолжается
процесс разработки.

>> Эта автоматика нужна во время финальной сборки, перед публикацией, не
>> во время активной разработки.
> А потом вы жалуетесь что автоматика срабатывает слишком поздно, когда
> пакет уже собран. Надо определяться, чего именно хочется. Хочется
> правильной сборки - не отключайте проверку.
Автоматика с sisyphus_check и repocop очень нормальная и своевременная
и хорошо, что отключаемая. Хочется, чтобы уметь менять rpm без
пересборки. И без проверок. Ибо так иногда НАДО. Чтобы предупредить
всякие обвинения я заранее говорю, что поддерживаю то, что пакетам не
проходящим sisyphus_check в Сизифе не место. Но я еще раз говорю, что
пакеты бывают не только для Сизифа и остальных публичных репозиториев.

> да все обновляется, через rpm. Но вы ж должны понимать, что без смены
> релиза результат вашего дистрибутива можно ставить только вашим
> тестерам и более никому. Пока это между вами и тестером - пользуйтесь
> чем угодно. Но в люди выходить без смены релиза - засмеют.
rpm, да. А вот apt'ом -- нет.

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

А вот когда пройдет этап разработки, то конечно мы все соберем
начисто, все проверим всеми возможнымипроверками и отдадим
пользователям.

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

Re: [devel] поддержка пакетов в git

[Aleksey Avdeev]

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

Dmitriy M. Maslennikov пишет:
> 25 сентября 2008 г. 14:50 пользователь Damir Shayhutdinov
> <damir@altlinux.org> написал:
...
>> Синхронизоваться надо если есть общий ресурс. Если общего ресурса нет
>> - синхронизация не нужна.
>> Общий ресурс в данном случае - версия + релиз.
>>
>> Правило изменения версий и релизов пакетов в Сизифе или в
>> дистрибутивах Альта вам известно. Вам надо лишь обеспечить чтобы ваши
>> собственные релизы не пересекались
>>
>> Решение: использовать те же правила, что и для бекпортов.
>> Как один из вариантов - делайте версию -altN.maslM.
> Есть задача: заменить один из пакетов в Сизифе. Как этого добиться не
> понимаю, разве что с помощью serial, но что если в Сизифе сериал
> поднимется выше моего?

   Помоем здесь очевидный путь -- пакет с отличающимся именем (и 
предоставляющий нужные зависимости).

-- 

С уважением. Алексей.



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 552 bytes --]

Re: [devel] поддержка пакетов в git

[Led]

On Wednesday, 24 September 2008 16:42:39 Dmitriy M. Maslennikov wrote:

> > Ради смены скриптов установки? конечно.
>
> Это по вашему не оверхед? Если я в одном символе, где-нибудь в %post в
> том же openoffice опечатался, то неприменно должен его пересобрать?

Да вы не только про "rpm -bs" ничего не знаете, но также и 
про "--short-circuit" не слышали???

-- 
Led

Re: [devel] поддержка пакетов в git

[Vitaly Lipatov]

On 24 сентября 2008, Led wrote:
> On Wednesday, 24 September 2008 16:42:39 Dmitriy M. Maslennikov 
wrote:
> > > Ради смены скриптов установки? конечно.
> >
> > Это по вашему не оверхед? Если я в одном символе, где-нибудь
> > в %post в том же openoffice опечатался, то неприменно должен
> > его пересобрать?
>
> Да вы не только про "rpm -bs" ничего не знаете, но также и
> про "--short-circuit" не слышали???
Работает нормально только в альтовом rpm. И что насчёт сборки в 
hasher?


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

Re: [devel] поддержка пакетов в git

[Alexey Tourbin]

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

On Wed, Sep 24, 2008 at 03:42:55PM +0400, Dmitriy M. Maslennikov wrote:
> Я так понимаю, что по сути пакет -- это набор файлов со скриптами
> установки/удаления. Репозитарий набор пакетов, причем удобный для
> обновления. Changelog -- это история изменения пакета В РЕПОЗИТАРИИ, а
> не пакета вообще. Но почему-то его запихнули в пакет. Для чего? Почему
> changelog указывается перед сборкой пакета, а не в момент помещения
> его в репозитарий?

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

История изменения пакета вполне относится к самому пакету (особенно это
касается *исходников* пакета).  С другой стороны, *собранный* пакет
существует только в рамках того репозитария, в котором его удалось
собрать (если при этом не возникло анметов и т.п.).

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

Зачаток правильной модели данных написан здесь:
ftp://ftp.altlinux.org/pub/people/at/protva-2008.pdf
(первый абзац это самое важное).

Остальные модели неправильные.

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

Re: [devel] поддержка пакетов в git

[Dmitriy M. Maslennikov]

25 сентября 2008 г. 20:35 пользователь Alexey Tourbin <at@altlinux.ru> написал:
> Вы беретесь рассуждать на сложные темы, которые Вам не по зубам.
> Вам, скажем, известно, что такое "антиномии"?
Смешно) Но вы меня не знаете. Так что прошу без перехода на личности.

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

> Нужна адекватная модель данных, которая, с одной стороны, поддерживает
> автономное представление о пакетах, с другой стороны, учитывает
> "глобальные" гетерономные эффекты (взаимное влияние пакетов друг на
> друга).
Нужна. Ее нет. При этом считаю, что все-равно в праве критиковать и apt и rpm.

> Зачаток правильной модели данных написан здесь:
> ftp://ftp.altlinux.org/pub/people/at/protva-2008.pdf
> (первый абзац это самое важное).
Я ваши тезисы к докладу уже читал. Жаль, что вы не выступили с
докладом на конференции.

> Остальные модели неправильные.
Ваша единственно верная? Математическое доказательство
единственноверности приведете?

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

Re: [devel] поддержка пакетов в git

[Alexey Tourbin]

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

On Thu, Sep 25, 2008 at 08:53:29PM +0400, Dmitriy M. Maslennikov wrote:
> > Вы беретесь рассуждать на сложные темы, которые Вам не по зубам.
> > Вам, скажем, известно, что такое "антиномии"?
> Смешно) Но вы меня не знаете. Так что прошу без перехода на личности.

Вы писали: "Changelog -- это история изменения пакета В РЕПОЗИТАРИИ,
а не пакета вообще".  При чем тут знаю я Вас или нет.  У меня
естественно возникает интерес, на каком уровне находится это Ваше
рассуждение, на уровне детского сада или на уровне какого-то
образования.  В зависимости от этого какое-либо обсуждение может
состояться или нет, так что в некотором (огранченном) смысле "переход
на личности" неизбежен.

> > Нужна адекватная модель данных, которая, с одной стороны, поддерживает
> > автономное представление о пакетах, с другой стороны, учитывает
> > "глобальные" гетерономные эффекты (взаимное влияние пакетов друг на
> > друга).
> Нужна. Ее нет. При этом считаю, что все-равно в праве критиковать и apt и rpm.

JFYI, при наличии дубликатов можно попросить apt поставить любую
из имеющихся версий пакетов, а не обязательно самую новую:
# apt-get install foo=1.0-alt1

Критиковать rpm смысла нет, это yes/no thing.  То есть rpm никак не
может влиять на входные данные, а может только их обрабатывать.  Тогда
он говори либо "да" (и устанавливает пакеты), либо "нет" (и отваливает).

С apt спрос другой, но и с него нельзя требовать слишком много.

> > Зачаток правильной модели данных написан здесь:
> > ftp://ftp.altlinux.org/pub/people/at/protva-2008.pdf
> > (первый абзац это самое важное).
> Я ваши тезисы к докладу уже читал. Жаль, что вы не выступили с
> докладом на конференции.

Расхотелось мне выступать, по разным причинам.

> > Остальные модели неправильные.
> Ваша единственно верная? Математическое доказательство
> единственноверности приведете?

Модель не является предметом доказательства.  Вы просто ничего не понимаете.
http://ru.wikipedia.org/wiki/Теория_моделей

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

Re: [devel] поддержка пакетов в git

[Dmitriy M. Maslennikov]

25 сентября 2008 г. 21:23 пользователь Alexey Tourbin <at@altlinux.ru> написал:
> Вы писали: "Changelog -- это история изменения пакета В РЕПОЗИТАРИИ,
> а не пакета вообще".  При чем тут знаю я Вас или нет.  У меня
> естественно возникает интерес, на каком уровне находится это Ваше
> рассуждение, на уровне детского сада или на уровне какого-то
> образования.  В зависимости от этого какое-либо обсуждение может
> состояться или нет, так что в некотором (огранченном) смысле "переход
> на личности" неизбежен.
Ок, можете считать, что я учусь в одиннадцатом классе. Так что об
образовании в академическом смысле речь не идет.

> JFYI, при наличии дубликатов можно попросить apt поставить любую
> из имеющихся версий пакетов, а не обязательно самую новую:
> # apt-get install foo=1.0-alt1
Я имел в виду не просить apt, о чем либо, а просить его об обновлении.
dist-upgrade -- это практически единственное, что необходимо знать
пользователю (не разработчику).

> Критиковать rpm смысла нет, это yes/no thing.  То есть rpm никак не
> может влиять на входные данные, а может только их обрабатывать.  Тогда
> он говори либо "да" (и устанавливает пакеты), либо "нет" (и отваливает).
Есть, он очень неудобен. К сожалению, люди с математическим
образованием часто любят логическую безупречность, чем удобство. Но те
для которых мы все это делаем чаще ценят удобство.

>> > Зачаток правильной модели данных написан здесь:
>> > ftp://ftp.altlinux.org/pub/people/at/protva-2008.pdf
>> > (первый абзац это самое важное).
Только там больше про сборку пакетов рассуждения. А я критикую apt и
rpm в плане неудобства использования и неудобной модели обновления у
apt'а.

>> > Остальные модели неправильные.
>> Ваша единственно верная? Математическое доказательство
>> единственноверности приведете?
>
> Модель не является предметом доказательства.  Вы просто ничего не понимаете.
> http://ru.wikipedia.org/wiki/Теория_моделей
Модель нет. Я просил доказать утверждение "Остальные модели неправильные."

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

Re: [devel] поддержка пакетов в git

[Alexey Tourbin]

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

On Fri, Sep 26, 2008 at 11:04:09AM +0400, Dmitriy M. Maslennikov wrote:
> >> > Остальные модели неправильные.
> >> Ваша единственно верная? Математическое доказательство
> >> единственноверности приведете?
> > Модель не является предметом доказательства.  Вы просто ничего не понимаете.
> > http://ru.wikipedia.org/wiki/Теория_моделей
> Модель нет. Я просил доказать утверждение "Остальные модели неправильные."

Это достаточно сложно.  Теория означает определенные правила
преобразования "значков".  Модель означает "интерпретацию", связь между
преобразованиями значков и понятиями предметной области.

Почему модель может быть "правильной"?  Модель может быть правильной,
потому что она соответствует действительности.  Теория объективной
истины (Тарский) определяет истинность высказываний на основе их
соответствия фактам (см. Поппер "Предположения..." 2004 с.371-).

У меня теория и модель несколько более размыты.  Рассмотрим постулат
теории B(S,C)->P, который описывает некий базовый способ преобразования
символов.  Интерпретация состоит в том, что функция B осуществляет
сборку пакета S в среде C, а на выходе даёт собранные пакеты P.

Эта модель является "правильной" потому, что она соответствует фактам.
А именно, если хешер B поставил в чрут пакеты С и подал на вход S
исходники, тогда на выходе должны получиться P собранные пакеты.

Если же мы будем собирать исходники S в другом чруте C1 (с отличным
содержимым), то мы получим на выходе уже другие пакты P1 (которые имеют
право отличаться).

Модель является правильной, когда она соответствует действительности;
а действительность состоит в том, что исходники пакета S собираются в
сборочной среде C.  Значит, правильная модель будет запрещать, как
минимум, допустим, две вещи:

1) "Варить" пакеты какое-то время в недостаточно зафиксированной среде
(чтобы среда C менялась недостаточно определённым образом).
2) "Перекладывать" пакеты из одной среды в другую (так как в
действительности среда C определяет результат сборки: С->P,
а в другой сборочной среде уже будет C1->P1).

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

Посмотрим теперь, каким образом постулат B(S,C)->P может определять
дальнейшую модель.  Понятие C (сборочный чрут) я изначально специально
не конкретизирую; но в *действительности* ясно, что С на самом деле
является множеством ранее собранных пакетов: С=[P_0...].

Тогда постулат B(S,C)->P дает древовидную историю развития пакетов:

        B(S,C)->P
            ^
	    |
    B(S,C)->P
        ^
        |
B(S,C)->P

Это (более или менее) естественным образом приводит к идее
"метарепозатиария", которая изложена в последнем разделе тезисов.

Короче, модель является правильной, если она соответствует фактам; тому,
что происходит на самом деле.  А если модель не соответствует фактам,
тому, что происходит на самом деле, тогда она является неправильной.
В смысле сборки пакетов правильными являются только такие модели,
которые основываются на постулате B(S,C)->P.

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

Re: [devel] поддержка пакетов в git

[Mikhail Gusarov]

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

Twas brillig at 20:50:00 27.09.2008 UTC+00 when at@altlinux.ru did gyre and gimble:

 AT> В смысле сборки пакетов правильными являются только такие модели,
 AT> которые основываются на постулате B(S,C)->P.

Извини, не удержался:

"Умение решать проблемы - это критично. Умные люди, не умеющие
справляться с проблемами, часто имеют степени и работают в больших
компаниях, где их никто не слушает из-за их полной непрактичности. Они
скорее станут думать об академическом подходе к проблеме, а не о выпуске
продукта в срок. Их можно опознать по любви к поиску теоретического
сходства между двумя крайне различающимися концепциями. Например, они
могут заявить "Таблицы - это, в сущности, особый случай языка
программирования", затем исчезнуть на неделю и написать потрясающую
статью о теоретических атрибутах вычислительной лингвистики электронных
таблиц как языка программирования. Это круто, но бесполезно."

Спольски, кажется.

Nothing Personal.

-- 

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

Re: [devel] поддержка пакетов в git

[Alexey Tourbin]

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

On Sun, Sep 28, 2008 at 03:57:10AM +0700, Mikhail Gusarov wrote:
>  AT> В смысле сборки пакетов правильными являются только такие модели,
>  AT> которые основываются на постулате B(S,C)->P.
> 
> Извини, не удержался:
> 
> "Умение решать проблемы - это критично. Умные люди, не умеющие
> справляться с проблемами, часто имеют степени и работают в больших
> компаниях, где их никто не слушает из-за их полной непрактичности. Они
> скорее станут думать об академическом подходе к проблеме, а не о выпуске
> продукта в срок. Их можно опознать по любви к поиску теоретического

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

> сходства между двумя крайне различающимися концепциями. Например, они
> могут заявить "Таблицы - это, в сущности, особый случай языка
> программирования", затем исчезнуть на неделю и написать потрясающую
> статью о теоретических атрибутах вычислительной лингвистики электронных
> таблиц как языка программирования. Это круто, но бесполезно."

Это вовсе не бесполезно.

> Спольски, кажется.
> Nothing Personal.

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

Re: [devel] поддержка пакетов в git

[Mikhail Gusarov]

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

Twas brillig at 20:50:00 27.09.2008 UTC+00 when at@altlinux.ru did gyre and gimble:

А теперь по существу.

 AT> Посмотрим теперь, каким образом постулат B(S,C)->P может определять
 AT> дальнейшую модель.  Понятие C (сборочный чрут) я изначально
 AT> специально не конкретизирую; но в *действительности* ясно, что С на
 AT> самом деле является множеством ранее собранных пакетов: С=[P_0...].

Это приведёт к уже упомянутому холизму.

Не появилось ли у тебя идей, как искать прообразы каждого P относительно
функции B или хотя бы определять (без сборки), <S1,C1> =1 <S2,C2>, где
=1 - тогда, когда B(S1,C1) = B(S2,C2)? Факторизовать область определения
B относительно P не получится, но оно и не надо.

-- 

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

Re: [devel] поддержка пакетов в git

[Alexey Tourbin]

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

On Sun, Sep 28, 2008 at 04:04:12AM +0700, Mikhail Gusarov wrote:
> А теперь по существу.
> 
>  AT> Посмотрим теперь, каким образом постулат B(S,C)->P может определять
>  AT> дальнейшую модель.  Понятие C (сборочный чрут) я изначально
>  AT> специально не конкретизирую; но в *действительности* ясно, что С на
>  AT> самом деле является множеством ранее собранных пакетов: С=[P_0...].
> 
> Это приведёт к уже упомянутому холизму.
> 
> Не появилось ли у тебя идей, как искать прообразы каждого P относительно
> функции B или хотя бы определять (без сборки), <S1,C1> =1 <S2,C2>, где
> =1 - тогда, когда B(S1,C1) = B(S2,C2)? Факторизовать область определения

Равенство =1 нельзя определить иначе, кроме как экстенсионально;
то есть при S1!=S2 или С1!=С2 никакого равенства быть не может.

> B относительно P не получится, но оно и не надо.

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

Re: [devel] поддержка пакетов в git

[Alexey Tourbin]

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

On Sat, Sep 27, 2008 at 09:19:54PM +0000, Alexey Tourbin wrote:
> > Не появилось ли у тебя идей, как искать прообразы каждого P относительно
> > функции B или хотя бы определять (без сборки), <S1,C1> =1 <S2,C2>, где
> > =1 - тогда, когда B(S1,C1) = B(S2,C2)? Факторизовать область определения
> 
> Равенство =1 нельзя определить иначе, кроме как экстенсионально;
> то есть при S1!=S2 или С1!=С2 никакого равенства быть не может.

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

Пусть B(S,C1)->P1 и B(S,C2)->P2.
Тогда, если C1<C2, то P1<P2.

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

Re: [devel] поддержка пакетов в git

[Dmitriy M. Maslennikov]

28 сентября 2008 г. 1:29 пользователь Alexey Tourbin <at@altlinux.ru> написал:
> Но можно ввести отношение частичного порядка, которое означает
> совместимость ранее собранных пакетов в более новой среде.
>
> Пусть B(S,C1)->P1 и B(S,C2)->P2.
> Тогда, если C1<C2, то P1<P2.
Все очень круто, но я говорил не об этом.

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

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

От софта навроде apt я ожидаю, напротив большого интелекта.

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

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

Re: [devel] поддержка пакетов в git

[Kirill A. Shutemov]

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

On Sat, Sep 27, 2008 at 08:50:00PM +0000, Alexey Tourbin wrote:
> On Fri, Sep 26, 2008 at 11:04:09AM +0400, Dmitriy M. Maslennikov wrote:
> > >> > Остальные модели неправильные.
> > >> Ваша единственно верная? Математическое доказательство
> > >> единственноверности приведете?
> > > Модель не является предметом доказательства.  Вы просто ничего не понимаете.
> > > http://ru.wikipedia.org/wiki/Теория_моделей
> > Модель нет. Я просил доказать утверждение "Остальные модели неправильные."
> 
> Это достаточно сложно.  Теория означает определенные правила
> преобразования "значков".  Модель означает "интерпретацию", связь между
> преобразованиями значков и понятиями предметной области.
> 
> Почему модель может быть "правильной"?  Модель может быть правильной,
> потому что она соответствует действительности.  Теория объективной
> истины (Тарский) определяет истинность высказываний на основе их
> соответствия фактам (см. Поппер "Предположения..." 2004 с.371-).
> 
> У меня теория и модель несколько более размыты.  Рассмотрим постулат
> теории B(S,C)->P, который описывает некий базовый способ преобразования
> символов.  Интерпретация состоит в том, что функция B осуществляет
> сборку пакета S в среде C, а на выходе даёт собранные пакеты P.
> 
> Эта модель является "правильной" потому, что она соответствует фактам.
> А именно, если хешер B поставил в чрут пакеты С и подал на вход S
> исходники, тогда на выходе должны получиться P собранные пакеты.
> 
> Если же мы будем собирать исходники S в другом чруте C1 (с отличным
> содержимым), то мы получим на выходе уже другие пакты P1 (которые имеют
> право отличаться).
> 
> Модель является правильной, когда она соответствует действительности;
> а действительность состоит в том, что исходники пакета S собираются в
> сборочной среде C.  Значит, правильная модель будет запрещать, как
> минимум, допустим, две вещи:
> 
> 1) "Варить" пакеты какое-то время в недостаточно зафиксированной среде
> (чтобы среда C менялась недостаточно определённым образом).
> 2) "Перекладывать" пакеты из одной среды в другую (так как в
> действительности среда C определяет результат сборки: С->P,
> а в другой сборочной среде уже будет C1->P1).
> 
> Короче, почти все соображения о том, чтобы "варить" пакеты и вообще
> о "стабилизации" и "перекладывании" являются неправильными, потому
> что они пытаются игнорировать базовый принцип действительности
> (преобразования исходников в собранные пакеты, с фиксацией параметров
> преобразования).
> 
> Посмотрим теперь, каким образом постулат B(S,C)->P может определять
> дальнейшую модель.  Понятие C (сборочный чрут) я изначально специально
> не конкретизирую; но в *действительности* ясно, что С на самом деле
> является множеством ранее собранных пакетов: С=[P_0...].

Есть ещё один фактор среды: ядро host системы. В обычной ситуации
различные ядра мало влияют на воспроизводимость сборки. Однако, в случае
использования qemu, в качестве ядра выступает пара: собственно, ядро host 
системы и qemu, которое обеспечивает трансляцию системных вызовов (и прочего)
между target и host системами. К сожалению, влияние qemu на воспроизводимость
сборки велико. Как можно вписать ядро в эту модель?

-- 
Regards,  Kirill A. Shutemov
 + Belarus, Minsk
 + ALT Linux Team, http://www.altlinux.com/

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

Re: [devel] поддержка пакетов в git

[Ivan A. Melnikov]

On Sunday 28 September 2008 00:50:00 Alexey Tourbin wrote:
>
> У меня теория и модель несколько более размыты.  Рассмотрим постулат
> теории B(S,C)->P, который описывает некий базовый способ преобразования
> символов.  Интерпретация состоит в том, что функция B осуществляет
> сборку пакета S в среде C, а на выходе даёт собранные пакеты P.
>

[...skip...]

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

Попробую возразить,  а то такая дискуссия заглохла...

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

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

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

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

-- 
Best regards,
Ivan A. Melnikov <iv@altlinux.org>

Re: [devel] поддержка пакетов в git

[Mykola S. Grechukh]

2008/9/30 Ivan A. Melnikov <>:
> Пакеты собираются для того, чтобы ими можно было пользоваться. К сожалению,
> достаточно сложно формализовать набор условий, при выполнении которых пакет
> может считаться полезным с этой точки зрения. Наиболее достоверным
> свидетельством того, что пакетом можно пользоваться, на данный момент, на мой
> взгляд, приходится считать тот факт, что им кто-то пользуется.

очевидно, факт "кто-то пользуется пакетом в среде S'" ничего не
говорит о работоспособности и устанавливаемости пакета в среде B.

Re: [devel] поддержка пакетов в git

[Ivan A. Melnikov]

On Tuesday 30 September 2008 18:12:32 Mykola S. Grechukh wrote:
> 2008/9/30 Ivan A. Melnikov <>:
> > Пакеты собираются для того, чтобы ими можно было пользоваться. К
> > сожалению, достаточно сложно формализовать набор условий, при выполнении
> > которых пакет может считаться полезным с этой точки зрения. Наиболее
> > достоверным свидетельством того, что пакетом можно пользоваться, на
> > данный момент, на мой взгляд, приходится считать тот факт, что им кто-то
> > пользуется.
>
> очевидно, факт "кто-то пользуется пакетом в среде S'" ничего не
> говорит о работоспособности и устанавливаемости пакета в среде B.
>

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

С другой стороны, если среды S и S' достаточно близки (в частности, чтобы и 
там, и там пакет можно было установить, но не ограничиваясь этим) то 
ИМХО "работоспособность в S" и "работоспособность в S'", не побоюсь этого 
слова, корелируют.

С третьей стороны, если пакет был собран в среде S, а тестировался в среде S', 
то о работоспосбности его в среде S можно сказать немногое.

-- 
Best regards,
Ivan A. Melnikov <iv@altlinux.org>

Re: [devel] поддержка пакетов в git

[Mykola S. Grechukh]

2008/9/30 Ivan A. Melnikov <>:
> С другой стороны, если среды S и S' достаточно близки (в частности, чтобы и
> там, и там пакет можно было установить, но не ограничиваясь этим) то
> ИМХО "работоспособность в S" и "работоспособность в S'", не побоюсь этого
> слова, корелируют.

это зависит еще и от полноты зависимостей пакета.

> С третьей стороны, если пакет был собран в среде S, а тестировался в среде S',
> то о работоспосбности его в среде S можно сказать немногое.

не больше можно сказать о его полезности в среде S', если был собран и
тестировался в среде S :)

Re: [devel] поддержка пакетов в git

[Ivan A. Melnikov]

On Tuesday 30 September 2008 18:53:22 Mykola S. Grechukh wrote:
> 2008/9/30 Ivan A. Melnikov <>:
> > С другой стороны, если среды S и S' достаточно близки (в частности, чтобы
> > и там, и там пакет можно было установить, но не ограничиваясь этим) то
> > ИМХО "работоспособность в S" и "работоспособность в S'", не побоюсь этого
> > слова, корелируют.
>
> это зависит еще и от полноты зависимостей пакета.
>
> > С третьей стороны, если пакет был собран в среде S, а тестировался в
> > среде S', то о работоспосбности его в среде S можно сказать немногое.
>
> не больше можно сказать о его полезности в среде S', если был собран и
> тестировался в среде S :)

Давайте пекратим этот обмен очевиднстями.  Если Вы пытались меня убедить, 
что "работоспособность у кого-то" -- плохой критерий, то зря, я и так это 
знаю. 

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

Я считаю эту информацию существенной и достаточной для того, чтобы 
пользоваться Сизифом. Для тех, кто считает иначе, существуют бранчи.

-- 
Best regards,
Ivan A. Melnikov <iv@altlinux.org>

Re: [devel] поддержка пакетов в git

[Alexey Tourbin]

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

On Tue, Sep 30, 2008 at 05:55:11PM +0400, Ivan A. Melnikov wrote:
> > У меня теория и модель несколько более размыты.  Рассмотрим постулат
> > теории B(S,C)->P, который описывает некий базовый способ преобразования
> > символов.  Интерпретация состоит в том, что функция B осуществляет
> > сборку пакета S в среде C, а на выходе даёт собранные пакеты P.

> > Короче, почти все соображения о том, чтобы "варить" пакеты и вообще
> > о "стабилизации" и "перекладывании" являются неправильными, потому
> > что они пытаются игнорировать базовый принцип действительности
> > (преобразования исходников в собранные пакеты, с фиксацией параметров
> > преобразования).
> 
> Попробую возразить,  а то такая дискуссия заглохла...
> 
> Пакеты собираются для того, чтобы ими можно было пользоваться. К сожалению, 
> достаточно сложно формализовать набор условий, при выполнении которых пакет 
> может считаться полезным с этой точки зрения. Наиболее достоверным 
> свидетельством того, что пакетом можно пользоваться, на данный момент, на мой 
> взгляд, приходится считать тот факт, что им кто-то пользуется.
> 
> С этой точки зрения пакет, пролежавший месяц в Сизифе, в среднем лучше, чем 
> пакет, только что собраный туда, несмотря на то, что последний собран в более 
> актуальной среде.
> 
> Безусловно, такая точка зрения игнорирует Базовый принцип действительности, 
> однако не противоречит ему. Более того, становится ясно, что для формирования 
> бранчей перекладывание предпочтительнее пересборки. 

Был по крайней мере один серьёзный прокол с перекладыванием пакетов
(где-то год назад): пакет amarok при перекладывании из Сизифа в 4.0
стал вываливаться с undefined символами.  И этот случай мог бы стать
далеко не едиственным, потому что Си+плюс ABI -- вещь особенно хрупакая.
Для просто Си ABI отслеживать несколько легче, но это всё ещё требует
ручной работы, а надёжной гарантии на уровне зависимостям не даёт.

Перекладывание "предпочтительнее" в смысле удобства, но не в смысле
гарантии целостности.

Собранный пакет P неявно ссылается на ту среду C (чрут), в которой он
был собран.  Принцип обратной совместимости можно формализовать через
частичное упорядочение: в новой среде C1>C пакет P будет работать в силу
обратной совместимости (что фактически и происходит при поступлении
новых пакетов в сизиф; мы же не делаем полную замещающую пересборку всех
пакетов, у которых обновилась сборочная среда).  А перекладывание в
бранчи означает прямо противоположную ситуацию: в более старой среде
C0<C никакой обратной совместимости быть не может (само понятие обратной
совместимости здесь неприменимо).

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

Требование можно расслабить для noarch пакетов, потому что для них
невозможны проколы на уровне ABI вроде случая с amarok.  Правда, можно
придумать нежелательные ситуации и для noarch пакетов (напр. lzma сжатие,
и вообще какие-либо предварительные требования к среде).

> Мне показалось, что Вы придаете очень большое значение тому, чтобы пакет 
> использовался в именно той среде, в которой он был собран. Я хотел бы 
> спросить, почему Вы так считаете, а также каким образом внедрение описанного 
> Вами в [ftp://ftp.altlinux.org/pub/people/at/protva-2008.pdf] метарепозитария 
> может изменить текущую ситуацию.

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

Я говорю о базовом принципе формирования целостного репозитария.
Нужно учитывать, какой пакет после какого собрался, и как это повлияло
на всё остальное.  Тогда мы имеем "историю коммитов" в репозитарии
(вполне по аналогии с git) и можем отслеживать взаимное влияние между
пакетами на очень тонком уровне.  Сейчас репозитарий формируется лишь
с довольно слабыми проверками целостности, а о взаимном влиянии между
пакетами мы узнаем при еженедельной пересборке пакетов.  Так что если
пакет перестал собираться, а в его сборочной среде изменилось более
одного пакета, тогда возникает двусмысленность: какой из обновившихся
пакетов сломал сборку?  А при правильном подходе разлом по сборке будет
автоматически отслеживаться с минимальной возможной грануляностью (то
есть на уровне пакета, если только не была затребована транзакция пачки
пакетов).

Идея метарепозитария (и соответствия его настоящему репозитарию)
несколько сурова, но она правдива, и она даёт гарантию и полную
настоящую картину развития репозитария.  По-видимому, эта идея должна
относиться только к базовому "репозитарию"/"бранчу" (напр.  как сейчас
4.0).  На основе базового репозитария можно сделать другие "пост-фактум
репозитарии" (как school-4.0), где метарепозитарий не играет роли, а
пакеты туда перекладывает вручную мистер Икс.

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

Re: [devel] поддержка пакетов в git

[Ivan A. Melnikov]

Спасибо за пояснения, многое стало понятнее. Ваши письма всегда интересно 
читать.

Мне нужно обдумать прочитанное. Скорее всего я вернусь к этой дискуссии позже.

-- 
Best regards,
Ivan A. Melnikov <iv@altlinux.org>

Re: [devel] поддержка пакетов в git

[Alexey Tourbin]

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

On Tue, Sep 30, 2008 at 07:50:01PM +0400, Alexey Tourbin wrote:
> Собранный пакет P неявно ссылается на ту среду C (чрут), в которой он
> был собран.  Принцип обратной совместимости можно формализовать через
> частичное упорядочение: в новой среде C1>C пакет P будет работать в силу
> обратной совместимости (что фактически и происходит при поступлении
> новых пакетов в сизиф; мы же не делаем полную замещающую пересборку всех
> пакетов, у которых обновилась сборочная среда).

Захотелось ещё раз отметить Базовый принцип (теории объективной истины):
так происходит на самом деле.  Ранее собранные пакеты всегда остаются
в репозитарии as is.

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