* [devel-distro] Наследование профилей в mkimage-profiles (was: Q: Что кладём в git) @ 2012-09-08 20:37 ` Michael Pozhidaev 2012-09-08 21:16 ` [devel-distro] Наследование профилей в mkimage-profiles Michael Shigorin 1 sibling, 1 reply; 7+ messages in thread From: Michael Pozhidaev @ 2012-09-08 20:37 UTC (permalink / raw) To: devel-distro Hello, Michael Shigorin! >> Файлы разных дистров хорошо раскладывать строго как отдельные файлы. > > Так загляни всё же в conf.d/ :) Фичи тоже можно делать "именные", > мало того, в плане ещё и иерархические (подготовка к которым > уже началась: b21353a00c5a8163111833b7d9009332f182fe54). Заглядывал, всё норм. Так вот, заглядываю в pkg.in, там списки пакетов. Туда будут попадать списки пакетов всех сборщиков? Опять та же проблема: если некоторый сборщик изменил свой список, а я его использовал, в моём дистрибутиве рождается непредсказуемая ситуация. Или можно так, чтобы там лежали забетонированные списки, которые меняются только с явным анонсом и обсуждением, а списки отдельных сборщиков лежали бы где-то в отдельных каталогах? Если я пока ещё плохо просёк философию, то прошу прощения, но эти вопросы кажутся совсем не такими уж маловажными. -- Michael Pozhidaev. Tomsk, Russia. Russian info page: http://www.marigostra.ru/ ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [devel-distro] Наследование профилей в mkimage-profiles 2012-09-08 20:37 ` [devel-distro] Наследование профилей в mkimage-profiles (was: Q: Что кладём в git) Michael Pozhidaev @ 2012-09-08 21:16 ` Michael Shigorin 2012-09-08 22:17 ` Michael Pozhidaev 0 siblings, 1 reply; 7+ messages in thread From: Michael Shigorin @ 2012-09-08 21:16 UTC (permalink / raw) To: devel-distro On Sun, Sep 09, 2012 at 03:37:23AM +0700, Michael Pozhidaev wrote: > >> Файлы разных дистров хорошо раскладывать строго как отдельные файлы. > > Так загляни всё же в conf.d/ :) Фичи тоже можно делать "именные", > > мало того, в плане ещё и иерархические (подготовка к которым > > уже началась: b21353a00c5a8163111833b7d9009332f182fe54). > Заглядывал, всё норм. Так вот, заглядываю в pkg.in, там списки > пакетов. Туда будут попадать списки пакетов всех сборщиков? Да. Но там прямщас можно namespaces -- или свой подкаталог (самое надёжное), или "именной" тег (а вот тут нюансы: a+b, a+b+c и a+b+MYTAG все попадут под выборку "a && b"). > Опять та же проблема: если некоторый сборщик изменил свой > список, а я его использовал, в моём дистрибутиве рождается > непредсказуемая ситуация. Предполагается, что по "чужим" основаниям и тегам подбирается конфигурация общего плана, а своя обязательная фиксируется жёстко и в явном виде. То есть всё естественным образом. Здесь пока самый неприятный вопрос -- "на вычитание". Добавил в HOWTO абзац следующего содержания: --- Следует заметить, что одной из основных идей метапрофиля является возможность комбинирования "неопределённости" в заданном направлении (часть задачи, формулируемая примерно как "нужен livecd") и точности в том, где есть конкретные требования (например, "firefox версии 10"). Выражается это в том, что можно основываться на уже существующих образах и фичах либо построить всё почти с нуля; можно брать существующие списки пакетов, а можно жёстко задать свои. Разумный баланс (точнее, его пределы) для каждого образа могут быть свои, но как общее правило -- для "любительских" проектов и семейств образов стоит смелей пользоваться наследованием, а вот "ответственные" образы может быть лучше конфигурировать с явным заданием необходимой пакетной базы (и в будущем -- юнит-тестов, которые надо утащить из m-p-d). --- http://www.altlinux.org/Mkimage/Profiles/m-p/howto > Или можно так, чтобы там лежали забетонированные списки, > которые меняются только с явным анонсом и обсуждением, а списки > отдельных сборщиков лежали бы где-то в отдельных каталогах? Да, конечно. Возможно, отрастут "платформы" (не путать с бранчами -- разницу в m-p, соответствующую бранчам, IMCO лучше поддерживать отдельными гитовыми ветками с внимательным cherry-pick при нужде). И в любом разе можно бетонировать списки в своём пространстве имён, даже если они будут содержать заведомые дубли. Кстати, инструментарий для отлова дублей можно взять в m-p-d::bin/pkgdups.sh; также оттуда думаю утащить bin/check-pkg-list, но пока не придумал, как бы сразу с порождаемыми aptbox интегрировать. Возможно, лучше в mkimage делать. > Если я пока ещё плохо просёк философию, то прошу прощения, > но эти вопросы кажутся совсем не такими уж маловажными. Мне тоже. Пока ты идёшь по уже продуманному и сделанному :) -- ---- WBR, Michael Shigorin <mike@altlinux.ru> ------ Linux.Kiev http://www.linux.kiev.ua/ ---- Sep 29, Kiev, Ukraine: -- http://conference.osdn.org.ua ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [devel-distro] Наследование профилей в mkimage-profiles 2012-09-08 21:16 ` [devel-distro] Наследование профилей в mkimage-profiles Michael Shigorin @ 2012-09-08 22:17 ` Michael Pozhidaev 2012-09-09 15:21 ` Michael Shigorin 0 siblings, 1 reply; 7+ messages in thread From: Michael Pozhidaev @ 2012-09-08 22:17 UTC (permalink / raw) To: shigorin; +Cc: Distributions development Hello, Michael Shigorin! >> Или можно так, чтобы там лежали забетонированные списки, >> которые меняются только с явным анонсом и обсуждением, а списки >> отдельных сборщиков лежали бы где-то в отдельных каталогах? > > Да, конечно. Возможно, отрастут "платформы" (не путать с бранчами > -- разницу в m-p, соответствующую бранчам, IMCO лучше поддерживать > отдельными гитовыми ветками с внимательным cherry-pick при нужде). > > И в любом разе можно бетонировать списки в своём пространстве > имён, даже если они будут содержать заведомые дубли. У меня конструктивное предложение: оговорить список базовых пакетных групп, которые могут быть основой дистрибутивов. Дистрибутивы будут подбирать их в зависимости от своей специфики. После какого-то момента, который, желательно, должен наступить пораньше, изменения в этих группах происходят только в случае расхождения с пакетной базой репозитория. Это можно использовать безопастно. Остальные группы находятся в поддержке сборщиков конкретных дистрибутивов. Их все используют на свой риск, поскольку по умолчанию сборщик не несёт ответственности за неожиданное изменение своей группы пакетов. Хорошо, если по файлу со списком можно быстро понять, от какого дистрибутива он тут появился. Аналогичное предложение и по скриптам, которые выполняют донастройку образов. У? -- Michael Pozhidaev. Tomsk, Russia. Russian info page: http://www.marigostra.ru/ ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [devel-distro] Наследование профилей в mkimage-profiles 2012-09-08 22:17 ` Michael Pozhidaev @ 2012-09-09 15:21 ` Michael Shigorin 2012-09-09 15:31 ` Michael Pozhidaev 0 siblings, 1 reply; 7+ messages in thread From: Michael Shigorin @ 2012-09-09 15:21 UTC (permalink / raw) To: Distributions development On Sun, Sep 09, 2012 at 05:17:01AM +0700, Michael Pozhidaev wrote: > У меня конструктивное предложение: оговорить список базовых > пакетных групп, которые могут быть основой дистрибутивов. Скажем так: я на сейчас не готов их формировать сам, но предложения принимаются. Можно записать как одно из требований к условной версии 1.0. > После какого-то момента, который, желательно, должен наступить > пораньше, изменения в этих группах происходят только в случае > расхождения с пакетной базой репозитория. Надо всё как следует обдумать, перекликается с уже известными вопросами на тему внутренних/внешних API/ABI и прочими темами вида "разработка vs стабильность". > Остальные группы находятся в поддержке сборщиков конкретных > дистрибутивов. Их все используют на свой риск, поскольку по > умолчанию сборщик не несёт ответственности за неожиданное > изменение своей группы пакетов. Есть предложение пока не пытаться угадать сразу, а помучиться с тем, что имеется, набить и проанализировать небольшое количество шишек и решать уже обоснованно. Альтернативные предложения, разумеется, тоже принимаются :) -- ---- WBR, Michael Shigorin <mike@altlinux.ru> ------ Linux.Kiev http://www.linux.kiev.ua/ ---- Sep 29, Kiev, Ukraine: -- http://conference.osdn.org.ua ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [devel-distro] Наследование профилей в mkimage-profiles 2012-09-09 15:21 ` Michael Shigorin @ 2012-09-09 15:31 ` Michael Pozhidaev 2012-09-09 16:59 ` Michael Shigorin 0 siblings, 1 reply; 7+ messages in thread From: Michael Pozhidaev @ 2012-09-09 15:31 UTC (permalink / raw) To: shigorin; +Cc: Distributions development Hello, Michael Shigorin! > Скажем так: я на сейчас не готов их формировать сам, > но предложения принимаются. Можно записать как одно из > требований к условной версии 1.0. Ну попробую собрать что-нибудь своё, пришлю комментарий, что и как получилось, как лучше всё разложить по группам. Вопрос: как договоримся определять принадлежность группе конкретному сборщику (дистрибутиву)? -- Michael Pozhidaev. Tomsk, Russia. Russian info page: http://www.marigostra.ru/ ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [devel-distro] Наследование профилей в mkimage-profiles 2012-09-09 15:31 ` Michael Pozhidaev @ 2012-09-09 16:59 ` Michael Shigorin 0 siblings, 0 replies; 7+ messages in thread From: Michael Shigorin @ 2012-09-09 16:59 UTC (permalink / raw) To: Distributions development On Sun, Sep 09, 2012 at 10:31:12PM +0700, Michael Pozhidaev wrote: > Вопрос: как договоримся определять принадлежность группе > конкретному сборщику (дистрибутиву)? По сборщикам пока прецедентов не было, можно предложить префикс в виде логина; по дистрибутивам -- см. conf.d/simply.mk и features.in/slinux/ (хорошо бы ликвидировать разночтение, btw). -- ---- WBR, Michael Shigorin <mike@altlinux.ru> ------ Linux.Kiev http://www.linux.kiev.ua/ ---- Sep 29, Kiev, Ukraine: -- http://conference.osdn.org.ua ^ permalink raw reply [flat|nested] 7+ messages in thread
[parent not found: <m3y5kkntac.fsf@blard.localdomain>]
* Re: [devel-distro] Q: Что кладём в git @ 2012-09-09 17:02 ` Michael Shigorin 0 siblings, 0 replies; 7+ messages in thread From: Michael Shigorin @ 2012-09-09 17:02 UTC (permalink / raw) To: devel-distro On Sun, Sep 09, 2012 at 03:39:23AM +0700, Michael Pozhidaev wrote: > Значительно важнее те вопросы, про которые тебе пишу, т.е. что > влияет на вероятность модификации, которая пройдёт у меня за спиной. Вот и обдумываю инструментарий, который бы позволил подобное удобно отслеживать. Пока даже намёток идей нет, увы. Как минимум -- можно сравнивать distcfg.mk, часть изменений по дороге такая проверка отловит (но не в пакаджлистах или скриптах). А!! Можно сравнивать сгенерированные профили :) Они же специально мелкие и as-needed. PS: тоже возвращаю в рассылку, т.к. вопрос (и ответ) могут быть более широко интересны. -- ---- WBR, Michael Shigorin <mike@altlinux.ru> ------ Linux.Kiev http://www.linux.kiev.ua/ ---- Sep 29, Kiev, Ukraine: -- http://conference.osdn.org.ua ^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2012-09-09 17:02 UTC | newest] Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2012-09-08 20:37 ` [devel-distro] Наследование профилей в mkimage-profiles (was: Q: Что кладём в git) Michael Pozhidaev 2012-09-08 21:16 ` [devel-distro] Наследование профилей в mkimage-profiles Michael Shigorin 2012-09-08 22:17 ` Michael Pozhidaev 2012-09-09 15:21 ` Michael Shigorin 2012-09-09 15:31 ` Michael Pozhidaev 2012-09-09 16:59 ` Michael Shigorin 2012-09-09 17:02 ` [devel-distro] Q: Что кладём в git Michael Shigorin
ALT Linux Distributions development This inbox may be cloned and mirrored by anyone: git clone --mirror http://lore.altlinux.org/devel-distro/0 devel-distro/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-distro devel-distro/ http://lore.altlinux.org/devel-distro \ devel-distro@lists.altlinux.org devel-distro@lists.altlinux.ru devel-distro@lists.altlinux.com public-inbox-index devel-distro Example config snippet for mirrors. Newsgroup available over NNTP: nntp://lore.altlinux.org/org.altlinux.lists.devel-distro AGPL code for this site: git clone https://public-inbox.org/public-inbox.git