From: Aleksey Avdeev <solo@solin.spb.ru> To: ALT Linux Team development discussions <devel@lists.altlinux.org> Subject: Re: [devel] non-strict deps Зачем? Date: Sat, 26 Jan 2013 22:55:33 +0400 Message-ID: <510426A5.9020708@solin.spb.ru> (raw) In-Reply-To: <20130126133250.GB3629@altlinux.org> [-- Attachment #1: Type: text/plain, Size: 5808 bytes --] 26.01.2013 17:32, Dmitry V. Levin пишет: > On Sat, Jan 26, 2013 at 04:35:37PM +0400, Alexey Gladkov wrote: >> 26.01.2013 16:08, Dmitry V. Levin wrote: >>> Разве это не очевидно? Вы же не первый год в теме, и знаете, что >>> одновременная установка подпакета одной версии с подпакетом другой версии >>> чревата большими неприятностями, такие смешанные установки вряд ли кто-то >>> в состоянии полноценно протестировать, поэтому лучшее, что мы можем >>> сделать - это избегать их. >> >> Это не очевидно. > > Это не вполне тривиально, но все равно очевидно. Это далеко не очевидно. Для меня очевидно обратное, когда речь идёт о внутрипакетных зависимостях подпакетов с конфигами (вариантами конфигурации чего либо) и модулями -- и в том и в другом случаи для меня очевидна ценность возможностей: а) обновить только заданный подпакет, не трогая остальное; б) поставить подпакет на hold и обновить остальное; в) заменить подпакет его альтернативой, собранной из другого источника. Да, этими возможностями можно пользоваться не всегда: изменения интерфейса работы с модулями (его ABI) и инфраструктурные изменения в подсистемах могут приводить к нерабочим конфигурациям. Но такие конфигурации можно отстрелить вдумчивой расстановкой Provides/Conflicts/Requires и указанием зависимостей на файлы/каталоги. > >> Нестрогие зависимости это инструмент. Он не может быть хорош или плох. > > Нестрогие зависимости редко когда инструмент, чаще это свойство. В моих пакетах это именно инструмент. И ручная работа над Provides/Conflicts/Requires и файловыми зависимостями (с соответсвующей потерей времени) -- плата за его применение. Прошу указать когда его применение к моим пакетам приводило к проблемам, в виде неработоспособности пакета из-за рассинхронизации его компонент. (По моему у меня уже давно такого не было.) > >> Любой инструмент если его неправильно применять будет приносить вред. >> Стоит ли бороться с неправильным применением того или иного >> инструмента? Конечно да. Нужно ли из-за потенциального вреда запрещать >> инструмент? Мне кажется, что нет. >> >> Ты можешь привести конкретный пример из сизифа (как ты любишь), где >> нестрогая зависимость вызывает проблемы ? > > Ты думаешь, что это умозрительная проблема? Я несколько дней назад > посмотрел, что это за нечеткие зависимости в 659 исходных пакетах. > Там около процента альтернативных провайдеров типа vim-X11-* и > apache2-httpd-*, Сделанных мантейнерами _руками_, под их ответственность. Именно для них и нужна ручка, применение которой будет говорить о том, что мантейнер _знает_ что именно он делает (или что он считает что это так). > и очень много типовых ошибок упаковки, например, > нестрогая зависимость на используемую библиотеку (в пакете нет зависимости > вообще, а нестрогую зависимость на библиотеку вычислил find-requires). Здесь автозамена зависимостей на строгие нужна. > В этой ситуации сложнее привести пример, когда отсутствие строгой > зависимости не создает проблемы точечного обновления. set-versions > отслеживает только имена функций, этого не всегда бывает достаточно, > на эту тему висят баги: > https://bugzilla.altlinux.org/show_bug.cgi?id=28383 > Если обновить библиотеку, в которой не поменялся soname, но не обновить > devel-пакет (таких возможностей сейчас очень много), то можно получить > devel-пакет, в котором API не соответствует ABI в библиотеке. Между devel-пакетом и соответствующей ему библиотекой -- тоже. > > Так что это не просто неряшливые спеки приводят к неряшливым пакетам, > а еще и неряшливые пакеты - к проблемам точечных обновлений, которых можно > избежать с помощью строгих внутрипакетных зависимостей. Согласен полностью! Но не стоит под эту гребёнку вести случаи, где нестрогие зависимости мантейнер расставлял сам, руками!!! > >>>> Мы все доказываем и обосновываем тебе, что они нужны. >>> >>> Нет, вы не доказываете. >> >> Так ты тоже ещё ничего не доказал. Выше ты написал, что это очевидно. >> Но этот тред показывает, что для людей "не первый год в теме" >> полезность такого запрета совсем не очевидна. Поэтому, думаю, >> доказательство необходимости запрета всё-таки нужно (с плюсами и >> минусами). > > Необходимость запрета очевидна, неочевидна необходимость тотального > запрета. :) 1. Очевидна _безусловная_ необходимость запрета для связки библиотеки и её devel пакет. Возможно даже не только для библиотек, а вообще для всех подпакетов, требующихся для собираемого devel пакета. 2. Возможно полезен (но всё таки не очевиден) безусловный запрет нестрогих зависимостей для подпакетов связвнных через set-versions. 3. Очевиден вред от безусловного запрета нестрогих зависимостей для того что не попадает под пункты 1-2. Это конфиги, части не входящие в ядро пакета, но собираемые из одного источника (такие как модули) и пр. подобное. 3десь очевидна нужность нужен запрета по умолчанию, с возможностью его _ручного_ отключения. > >>> Я знаю, что такие ситуации >>> теоретически возможны, и тоже могу сочинить демонстрационный пример. >> >> Раз ты знаешь, что в таком механизме может быть необходимость, то >> почему не оставляешь возможности для него ? > > Я оставляю возможность такого механизма. Т. е. ручка всё таки будет? УРА!!! :-) > >>> Но на практике в Сизифе таких примеров либо нет совсем, либо их настолько >>> мало, что я за два дня не нашел. Помогите мне, найдите этот реальный >>> пример, тогда я верну механизм %_allowed_nonstrict_interdeps. >> >> И всё-таки давай вернёмся к osec. Пока есть хотя бы один пакет общее >> правило не применимо. Пока ты упорно игнорируешь этот случай. > > osec мы с тобой обсуждаем в соседнем треде. :) -- С уважением. Алексей. [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 900 bytes --]
next prev parent reply other threads:[~2013-01-26 18:55 UTC|newest] Thread overview: 73+ messages / expand[flat|nested] mbox.gz Atom feed top 2013-01-25 9:28 [devel] I: repocop NMU Igor Vlasenko 2013-01-25 9:56 ` Yuri N. Sedunov 2013-01-28 13:22 ` Igor Vlasenko 2013-01-25 9:57 ` Aleksey Avdeev 2013-01-25 10:10 ` Igor Vlasenko 2013-01-25 10:25 ` Aleksey Avdeev 2013-01-26 10:28 ` Aleksey Avdeev 2013-01-25 9:59 ` Alexey Gladkov 2013-01-25 10:11 ` Igor Vlasenko 2013-01-25 10:53 ` Dmitry V. Levin 2013-01-25 11:07 ` Aleksey Avdeev 2013-01-25 11:34 ` Dmitry V. Levin 2013-01-25 11:58 ` Aleksey Avdeev 2013-01-25 12:07 ` [devel] I: repocop NMU [JT] Sergei Epiphanov 2013-01-25 12:11 ` [devel] I: repocop NMU Aleksey Novodvorsky 2013-01-25 12:17 ` Dmitry V. Levin 2013-01-25 12:27 ` Sergey V Turchin 2013-01-25 12:35 ` Sergey V Turchin 2013-01-25 12:40 ` Dmitry V. Levin 2013-01-25 12:42 ` Sergey V Turchin 2013-01-25 13:00 ` Dmitry V. Levin 2013-01-25 13:01 ` Sergey V Turchin 2013-01-25 12:39 ` Dmitry V. Levin 2013-01-25 12:44 ` Sergey V Turchin 2013-01-25 12:13 ` Dmitry V. Levin 2013-01-25 12:26 ` Aleksey Avdeev 2013-01-25 12:10 ` Viacheslav Dubrovskyi 2013-01-25 12:13 ` Alexey Gladkov 2013-01-25 12:32 ` [devel] non-strict deps Dmitry V. Levin 2013-01-25 12:39 ` Aleksey Avdeev 2013-01-25 12:51 ` Dmitry V. Levin 2013-01-25 12:55 ` Alexey Gladkov 2013-01-25 13:00 ` Alexey Gladkov 2013-01-25 13:03 ` Dmitry V. Levin 2013-01-25 13:15 ` Alexey Gladkov 2013-01-25 14:48 ` [devel] osec_rpm_reporter Dmitry V. Levin 2013-01-26 11:21 ` Alexey Gladkov 2013-01-26 12:25 ` Dmitry V. Levin 2013-01-26 12:46 ` Alexey Gladkov 2013-01-26 13:05 ` Dmitry V. Levin 2013-01-26 14:38 ` Alexey Gladkov 2013-01-25 13:01 ` [devel] non-strict deps Aleksey Avdeev 2013-01-25 14:54 ` Led 2013-01-25 15:11 ` Dmitry V. Levin 2013-01-26 11:30 ` [devel] non-strict deps Зачем? Alexey Gladkov 2013-01-26 12:08 ` Dmitry V. Levin 2013-01-26 12:35 ` Alexey Gladkov 2013-01-26 13:32 ` Dmitry V. Levin 2013-01-26 18:55 ` Aleksey Avdeev [this message] 2013-01-28 11:33 ` Sergey V Turchin 2013-01-25 12:46 ` [devel] non-strict deps Alexey Gladkov 2013-01-25 12:50 ` Aleksey Avdeev 2013-01-25 12:58 ` Dmitry V. Levin 2013-01-25 13:00 ` Sergey V Turchin 2013-01-25 12:59 ` Sergei Epiphanov 2013-01-25 14:49 ` Led 2013-01-25 15:09 ` Dmitry V. Levin 2013-01-25 15:28 ` Aleksey Avdeev 2013-01-25 15:32 ` Sergey V Turchin 2013-01-25 15:38 ` Dmitry V. Levin 2013-01-25 15:40 ` Sergey V Turchin 2013-01-26 13:30 ` Sergey Vlasov 2013-01-26 14:17 ` Dmitry V. Levin 2013-01-26 16:19 ` Sergey Vlasov 2013-01-26 19:05 ` Aleksey Avdeev 2013-01-26 19:21 ` Dmitry V. Levin 2013-01-26 19:36 ` Sergey Vlasov 2013-01-26 19:14 ` Dmitry V. Levin 2013-01-26 20:44 ` Aleksey Avdeev 2013-01-27 7:07 ` Sergey Vlasov 2013-01-28 17:01 ` Dmitry V. Levin 2013-01-28 13:04 ` [devel] I: repocop NMU Igor Vlasenko 2013-01-28 13:15 ` Dmitry V. Levin
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=510426A5.9020708@solin.spb.ru \ --to=solo@solin.spb.ru \ --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