From: Alexey Tourbin <at@altlinux.ru> To: ALT Linux Team development discussions <devel@lists.altlinux.org> Subject: Re: [devel] правильные зависимости Date: Thu, 24 Mar 2011 03:36:51 +0300 Message-ID: <20110324003651.GK30247@altlinux.org> (raw) In-Reply-To: <20110323231713.GU9385@osdn.org.ua> On Thu, Mar 24, 2011 at 01:17:13AM +0200, Michael Shigorin wrote: > On Thu, Mar 24, 2011 at 01:03:28AM +0300, Alexey Tourbin wrote: > > > > Если рациональные аргументы не интересуют > > Сделай мне лично одолжение -- прочти вот эту статью: > http://egorfine.com/ru/articles/worse-than-failure/ Прочитал. Там написано, что надо признавать свои ошибки. Исправление зависимостей у *-devel пакетов ошибкой не является. В техническом отношении, по крайней мере. > > > Так их и не видно пока. Вещание в одни ворота. > > Рациональный аргумент у меня почти один - у пакетов должны быть > > правильные зависимости. > > Определи правильные зависимости, пожалуйста. Не докапываюсь, > просто когда подходит к трактовке слов, лучше сразу уточнить. Правильные зависимости - это все те и только те зависимости, которые обеспечивают работоспособность пакета, что обычно означает возможность использовать по прямому назначению его содержимое. Факторы работоспособности *-devel пакетов: 1) Возможность включать хедеры (т.е. должны быть зависимости на хедеры, которые включаются в свою очередь). 2) Возможность вызывать pkg-config (т.е. должны быть зависимости, которые обеспечивают Requires в *.pc файлах, иначе pkg-config откажется давать результат). 3) Возможность линковки. Если в .pc:Libs: указаны дополнительные библиотеки, то они должны быть поддержаны соответствующими зависимостями. Впрочем, настоящая необходимость указывать дополнительные библиотеки в Libs: возникает очень редко - дополнительные библиотеки в Libs: чаще всего находятся по ошибке, тогда как на самом деле им место в Libs.private. Все зависимости, которые не являются правильными, являются неправильными. > > Если от исправления зависимостей ломаются другие пакеты, то у > > других пакетов тоже неправильные зависимости, и они тоже должны > > быть исправлены. > > Смотри, это можно сделать двояко. Либо разгребя дорогу перед > теми, кто может добраться и помочь -- либо распинав их со своей > дороги и... и тогда своими руками. > > Мне кажется, что _правильным_ способом реализации той расчистки, > что ты задумал и начал делать не с того конца -- был бы такой: > > 1) анонс задумки в devel@; > 2) модификация buildreq для исключения случайных потерю полных BR; > 3) анализ сизифа на предмет предположительно лишних зависимостей; > 4) обсуждение полученного списка удалений по части особых случаев > ("так задумано для...") и документирование их в спеках; > 5) прогон buildreq -u по затрагивающимся пакетам (хорошо бы > заодно и версии/spec cleanup/патчи в апстрим...); > 6) когда хотя бы большая часть (пусть 80%) затронутых пакетов > получили зафиксированные полные сборочные зависимости, > можно вырезать лишние из графа; > 7) потихоньку фиксить остатки, имея под рукой (на вики, > здесь, лишь бы где-то был) текущий список оставшегося; > 8) когда пыль начнёт оседать, можно открутить дефолт для > buildreq назад к оптимизирующему (хотя IMHO хранить полный > список в закомментированном виде весьма полезно); > 9) и хорошо бы подвести итоги -- что было, что стало, > чего добились и что по дороге оказалось иначе. > > Такой подход куда более нудный, чем с шашкой в бой, но скажи, > в каких пунктах неправ и было бы предсказуемо хуже? Или тебе > просто такое неприемлемо? Это всё долго и глупо. По сути, надо сделать две вещи. Сначала исправить *-devel пакеты. Потом исправить пакеты, которые из-за этого сломались. Пакеты, которые явно сломались, видно в beehive_status. Исправить их не очень сложно. Некоторые пакеты стали собираться в урезанной конфигурации. Такие пакеты сложнее идентифицировать. Виновата в этом фирма альт линукс, а вовсе даже не Алексей Турбин, т.к. его идея интеграции тестовой пересборки в сборочную систему и создания метарепозитория материально-технически поддержана не была (хотя разговоров об этом было много). Лучшее, что у нас сейчас есть - это сравнение пакетов, которое в beehive после тестовой пересборки. Кстати это сравнение там не само вскочило - его кто-то закодил. Кажется, именно этот код теперь называют rpmdiff. > > Сохранине статуса-кво перед созданием нового бранча могло бы > > иметь некоторой смыл, хотя к рациональным аргументам это не > > отнсится. > > Rationale: стабилизировать реальней то, от чего знаешь, > чего ожидать (проверено собственноручно на 4.0/branch > и Terminal 4.0 -- по качеству он, похоже, вышел почти > как Master 2.4, если судить по отзывам). > > Contra: сделать вагон бинарно несовместимых изменений сразу после > бранча -- значит в который раз напороться на повышенные обяза^W > в смысле кровопотери по техническому бэкпортированию. > > В любом случае очень надеюсь, что бранч не свалится как снег > на голову.
next prev parent reply other threads:[~2011-03-24 0:36 UTC|newest] Thread overview: 47+ messages / expand[flat|nested] mbox.gz Atom feed top 2011-03-23 23:17 Michael Shigorin 2011-03-24 0:36 ` Alexey Tourbin [this message] 2011-03-24 1:03 ` Michael Shigorin 2011-03-24 1:04 ` Aleksey Novodvorsky 2011-03-24 7:48 ` Sergey Alembekov 2011-03-24 4:02 ` REAL 2011-03-24 9:08 ` [devel] rpmdiff Dmitry V. Levin 2011-03-24 9:31 ` [devel] правильные зависимости Dmitry V. Levin 2011-03-24 9:43 ` REAL 2011-03-24 9:53 ` Damir Shayhutdinov 2011-03-24 10:01 ` REAL 2011-03-24 10:45 ` Damir Shayhutdinov 2011-03-24 10:53 ` Dmitry V. Levin 2011-03-24 11:01 ` REAL 2011-03-24 11:09 ` Damir Shayhutdinov 2011-03-24 11:13 ` Dmitry V. Levin 2011-03-24 11:35 ` REAL 2011-03-24 12:59 ` Anton Farygin 2011-03-24 11:30 ` REAL 2011-03-24 11:37 ` Damir Shayhutdinov 2011-03-24 11:45 ` REAL 2011-03-24 11:42 ` Damir Shayhutdinov 2011-03-24 12:10 ` REAL 2011-03-24 11:43 ` Sergey Y. Afonin 2011-03-24 11:47 ` Damir Shayhutdinov 2011-03-24 11:50 ` Dmitry V. Levin 2011-03-24 11:55 ` Damir Shayhutdinov 2011-03-24 12:15 ` Michael Shigorin 2011-03-24 12:44 ` Damir Shayhutdinov 2011-03-24 13:00 ` Michael Shigorin 2011-03-24 13:22 ` Damir Shayhutdinov 2011-03-24 13:44 ` Michael Shigorin 2011-03-24 14:19 ` Damir Shayhutdinov 2011-03-24 16:21 ` Dmitry V. Levin 2011-03-24 17:29 ` Alexey Tourbin 2011-03-24 18:16 ` Michael Shigorin 2011-03-25 4:15 ` REAL 2011-03-24 10:08 ` Dmitry V. Levin 2011-03-24 10:56 ` Damir Shayhutdinov 2011-03-24 11:10 ` Dmitry V. Levin 2011-03-24 11:29 ` Damir Shayhutdinov 2011-03-24 14:07 ` Igor Vlasenko 2011-03-24 14:17 ` Igor Vlasenko 2011-03-24 14:29 ` Damir Shayhutdinov 2011-03-24 14:38 ` Igor Vlasenko 2011-03-24 9:46 ` [devel] devel deps optimization failure Dmitry V. Levin 2011-03-24 3:54 ` [devel] правильные зависимости REAL
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=20110324003651.GK30247@altlinux.org \ --to=at@altlinux.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