From: "Damir Shayhutdinov" <damir@altlinux.org> To: "ALT Linux Team development discussions" <devel@lists.altlinux.org> Subject: Re: [devel] поддержка пакетов в git Date: Thu, 25 Sep 2008 16:13:23 +0400 Message-ID: <679044850809250513o7a3f2a1aib297ca5abe1ff9db@mail.gmail.com> (raw) In-Reply-To: <47c0071b0809250421m18b9b4e5n17a4501695a75873@mail.gmail.com> >> Лично я не вижу препятствий, из-за которых мантейнеры второго >> репозитария не могли бы поддерживать >> возможность обновления с их репозитария до Сизифа например по тем же >> правилам, по которым поддерживаются >> пакеты в бранчах. > В целом да, только я скорее имел в виду не возможность обновления до > Сизифа, а именно репозиторий, как довесок к Сизифу, использующийся с > ним совместно. Гм. А тут тогда в чем проблема? Если это пакеты, которых в сизифе нет - пересечений быть не должно. >> Решение: использовать те же правила, что и для бекпортов. >> Как один из вариантов - делайте версию -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).
next prev parent reply other threads:[~2008-09-25 12:13 UTC|newest] Thread overview: 62+ messages / expand[flat|nested] mbox.gz Atom feed top 2008-09-24 10:50 Dmitry Afanasov 2008-09-24 11:42 ` Dmitriy M. Maslennikov 2008-09-24 12:06 ` Dmitry Afanasov 2008-09-24 12:25 ` Dmitriy M. Maslennikov 2008-09-24 12:59 ` Damir Shayhutdinov 2008-09-24 12:47 ` Damir Shayhutdinov 2008-09-24 13:42 ` Dmitriy M. Maslennikov 2008-09-24 14:42 ` Damir Shayhutdinov 2008-09-24 15:52 ` Dmitriy M. Maslennikov 2008-09-24 17:14 ` Led 2008-09-24 17:15 ` Andrey Rahmatullin 2008-09-24 17:36 ` Anton Farygin 2008-09-24 17:38 ` Andrey Rahmatullin 2008-09-24 20:39 ` Anton Farygin 2008-09-24 18:06 ` Led 2008-09-24 20:40 ` Anton Farygin 2008-09-24 17:28 ` Damir Shayhutdinov 2008-09-25 8:29 ` Dmitriy M. Maslennikov 2008-09-25 9:22 ` Damir Shayhutdinov 2008-09-25 9:59 ` Dmitriy M. Maslennikov 2008-09-25 10:50 ` Damir Shayhutdinov 2008-09-25 11:21 ` Dmitriy M. Maslennikov 2008-09-25 12:13 ` Damir Shayhutdinov [this message] 2008-09-25 12:37 ` Timur Batyrshin 2008-09-25 12:44 ` Damir Shayhutdinov 2008-09-25 14:29 ` Dmitriy M. Maslennikov 2008-09-25 14:43 ` Timur Batyrshin 2008-09-25 15:19 ` Dmitriy M. Maslennikov 2008-09-25 15:33 ` Damir Shayhutdinov 2008-09-25 17:35 ` Alexey I. Froloff 2008-09-26 6:56 ` Dmitriy M. Maslennikov 2008-09-26 8:35 ` Alexey I. Froloff 2008-09-25 14:51 ` Led 2008-09-25 15:32 ` Dmitriy M. Maslennikov 2008-09-25 15:36 ` Damir Shayhutdinov 2008-09-25 16:10 ` Dmitriy M. Maslennikov 2008-09-25 16:11 ` Dmitriy M. Maslennikov 2008-09-25 15:31 ` Damir Shayhutdinov 2008-09-25 16:07 ` Dmitriy M. Maslennikov 2008-09-25 12:28 ` Aleksey Avdeev 2008-09-24 17:12 ` Led 2008-09-24 19:20 ` Vitaly Lipatov 2008-09-25 16:35 ` Alexey Tourbin 2008-09-25 16:53 ` Dmitriy M. Maslennikov 2008-09-25 17:23 ` Alexey Tourbin 2008-09-26 7:04 ` Dmitriy M. Maslennikov 2008-09-27 20:50 ` Alexey Tourbin 2008-09-27 20:57 ` Mikhail Gusarov 2008-09-27 21:13 ` Alexey Tourbin 2008-09-27 21:04 ` Mikhail Gusarov 2008-09-27 21:19 ` Alexey Tourbin 2008-09-27 21:29 ` Alexey Tourbin 2008-09-28 6:08 ` Dmitriy M. Maslennikov 2008-09-28 5:55 ` Kirill A. Shutemov 2008-09-30 13:55 ` Ivan A. Melnikov 2008-09-30 14:12 ` Mykola S. Grechukh 2008-09-30 14:37 ` Ivan A. Melnikov 2008-09-30 14:53 ` Mykola S. Grechukh 2008-09-30 15:59 ` Ivan A. Melnikov 2008-09-30 15:50 ` Alexey Tourbin 2008-09-30 16:10 ` Ivan A. Melnikov 2008-09-30 16:55 ` Alexey Tourbin
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=679044850809250513o7a3f2a1aib297ca5abe1ff9db@mail.gmail.com \ --to=damir@altlinux.org \ --cc=devel@lists.altlinux.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
ALT Linux Team development discussions This inbox may be cloned and mirrored by anyone: git clone --mirror http://lore.altlinux.org/devel/0 devel/git/0.git # If you have public-inbox 1.1+ installed, you may # initialize and index your mirror using the following commands: public-inbox-init -V2 devel devel/ http://lore.altlinux.org/devel \ devel@altlinux.org devel@altlinux.ru devel@lists.altlinux.org devel@lists.altlinux.ru devel@linux.iplabs.ru mandrake-russian@linuxteam.iplabs.ru sisyphus@linuxteam.iplabs.ru public-inbox-index devel Example config snippet for mirrors. Newsgroup available over NNTP: nntp://lore.altlinux.org/org.altlinux.lists.devel AGPL code for this site: git clone https://public-inbox.org/public-inbox.git