From: ed@sam-solutions.net (Ed V. Bartosh) To: devel-kernel@altlinux.ru Subject: Re: [d-kernel] kernel policy Date: 16 Apr 2003 11:44:27 +0400 Message-ID: <m3znmqevj8.fsf@sam-solutions.net> (raw) In-Reply-To: <87he8zljh6.fsf@velvet.po.cs.msu.su> Hello, Peter n> kernel-patch-feat-%{upsteram_name} n> kernel-patch-fix-%{upstream_name} >> Предлагаю убрать patch- из названия: >> kernel-feat-%{upsteram_name} >> kernel-fix-%{upstream_name} >> >> По-моему достаточно информативно и короче. PN> это не информативно. это не говорит, что это -- патч. Может ещё PN> -source- убрать? Дык feat и fix будут говорить о том, что это патч, если уж так оно надо. Только зачем, никак не пойму. Какая от этого польза знать что это патч ? Давайте абстрагироваться :) Я вижу пакет kernel-feat-security-rsback - мне обязательно знать, что это патч ? Зачем ? >> И еще - а зачем вообще эти модули нужны ? Предлагаю избавиться от них >> или хотя бы минимизировать их количество. >> Или описать здесь принципы выноса бинарных модулей в отдельный пакет. >> Я как-то до сих пор их не уяснил :( PN> Это те модули которые уже вынесены. См. kernel-alsa-2.4.21pre-std-up PN> src rpm. Нет, не судьба называть их kernel-module. По-моему сейчас строится новая схема сборки. И существующие пакеты с бинарными модулями - это, возможно, анахронизм. С таким же успехом можно оставить старый принцип сборки ядра, опираясь на то, что такие ядра есть в Сизифе :) Где развитие ? Я не предлагаю их безоговорочно убрать. Определите принципы по которым будут создаваться такие пакеты. Принцип "потому, что так уже есть" мне представляется слабым доказательством. n> 2. Versioning пакетов. n> ---------------------- >> n> Пакетам с feat патчами желательно присваивать версии, полученные из n> upstream. Если upstream не делает versioning, допустимо называть их по n> дате последнего изменения upstream в формате ddmmyy. >> n> Пакетам с fix патчами обязательно присваивать версии по дате n> запаковывания в формате ddmmyy. >> Здесь можно привести формат имени таких пакетов. PN> secfixes. будут выглядеть именно так. Не понял, сорри. Как "так" ? kernel-fix-security- а дальше ? Нужно определить формат, как в случае с kernel-image, например. >> Вместе с патчами могут ставиться и тарболы, предлагаю их >> ставить в /usr/src/kernel/patches/src/<имя_патча>/ >> В отдельный пакет с сорцами уж точно нет смысла это выносить. PN> Да, но то как патч распологает свои файлы, -- не дело полиси, в этом PN> разбирается скрипт apply. Ты сам себе протифоречишь: Патчи. ---------- /usr/src/patches/<имя_патча>/* патчи patches/apply/<имя_патча> программа, которая прикладывает патчи Если не определить, где патчи будут хранить нужные им файлы - будет путаница. А смысл ? >> n> прикладывает патчи >> Считаю, что apply-программы вещь опциональная, а стандартное >> приложение патчей должно быть выполнено в виде макроса. >> Такой макрос уже есть. PN> Нет, не опциальная. Если нужно, -- можно сделать PN> /usr/lib/kernel-build-tools/apply, а все apply программы будут просто PN> соурсить этот файл. Можно, конечно и так. Мне показалось более элегантным решить это с помощью макроса. Давай я тебе его пришлю, а то так трудно разговаривать ? С помощью этого макроса я сейчас легко обхожусь без apply скриптов в большинстве пакетов (xfs, secfixes, evms прикладываются без проблем). >> n> Патчи внутри каталога могут находиться в любом расположении, это не n> определяется данным документом. >> Предлагаю определить, иначе будет затруднено вынесение общего >> функционала в макрос. PN> В среднем, будет один и тот же алгоритм. Но надо оставить за PN> патче-пакето-твроителями полную свободу в том, как и что патчить. Это путь к хаосу. Здесь, IMHO, лишняя свобода только вредит. Что плохого в том, что при взгляде в каталог с патчами будет виден порядок их приложения ? >> n> Программа прикладывающая патч, будучи вызванная из каталога с исходными n> текстами ядра, обязана приложить к ним нужные патчи или возвратить 1 в n> случае ошибки прикладывания. Программа может пользоваться следующими n> переменными окружения заданными при запуске в среде: n> - APPLIED_PATCHES, переменная содержит список названий уже приложенных n> патчей через запятую. n> - KVER, версия ядра, к которой нужно приложить патч. >> Не уверен, что это нужно. PN> Нужно. Почему не нужно? Сорри, я немного неправильно выразился. KVER нужно, а APPLIED_PATCHES и флажок ./patches/APPLIED_имя пакета дублируют друг друга. Я думаю, что флаг более универсален и прост в проверке, к тому же можно не только для пакета в целом его выставлять, а и для конкретных патчей тоже, если понадобится. А с переменной возни больше, однозначно. >> 2. Пачти называются NN-название.patch, где NN определяет порядок приложения. >> устанавливаются в /usr/src/kernel/patches/название_пакета/ PN> Это не регулируется policy. Дык и напрасно :) Собственно, это только мои предложения, решать тебе. >> 3. Условное приложение патчей достигается путем установки >> патча в каталог /usr/src/kernel/patches/название_пакета/название_required_пакета >> Такой патч будет приложен только при условии того, что приложены >> патчи из пакета 'название_required_пакета' PN> Это рекоммендованный но не обязательный способ. Согласен. Пусть будет рекомендательный. Это только первый шаг к условному приложению патчей. Мне порекомендовали, например, взглянуть на PATCH-O-MATIC, там есть на что посмотреть в этом плане. Может быть и есть смысл попользоваться их схемой. >> 4. При условии успешного приложения пакета патчей в каталоге ./patches >> соответствующего дерева kernel sources должен создаваться файл >> APPLIED_имя_пакета PN> Это рекоммендация. См. выше. >> 5. Тарболы с сорцами, используемыми пакетом с патчами устанавливаются в >> /usr/src/kernel/patches/src/название_пакета/ PN> это рекоммендация. Но, согласись, при такой схеме гораздо проще выяснить с какими файлами работает пакет. Почему бы ее и не применять ? >> 6. Стандартные действия по установке патчей производятся с помощью >> макроса(ов) из пакета kernel-build-tools PN> шелл-библиотеки из пакета kernel-build-tools, которая соурсится каждым PN> из apply-скриптов. Я не против, в принципе. Но почему тебе так не нравится идея с макросом ? Принципиальной разницы нет, IMHO. >> 7. Нестандартная действия по установке/приложению патчей производятся >> в скриптах имя_пакета-apply и устанавливаются в >> /usr/src/kernel/patches/apply PN> Не понимаю. Зачем делать условный оператор? Чтобы избавиться в большинстве случаев от apply скриптов. >> 9. В репозитарии не должно быть бинарных пакетов с модулями, все >> модули должны находиться в соответствующем kernel-image PN> Нет. Все модули, которые могут собираться отдельно от ядра собираются PN> отдельно от ядра. как то: alsa, i2c, lm_sensors, и так далее, PN> см. сизиф. См. Выше. -- Best regards, Ed V. Bartosh
next prev parent reply other threads:[~2003-04-16 7:44 UTC|newest] Thread overview: 80+ messages / expand[flat|nested] mbox.gz Atom feed top 2003-04-15 14:40 nidd 2003-04-15 13:56 ` Sviatoslav Sviridov 2003-04-15 16:05 ` [d-kernel] " Sergey Vlasov 2003-04-15 15:36 ` [d-kernel] " Ed V. Bartosh 2003-04-15 18:10 ` Peter Novodvorsky 2003-04-15 18:54 ` aen 2003-04-16 7:50 ` Ed V. Bartosh 2003-04-16 15:19 ` aen 2003-04-16 14:31 ` Ed V. Bartosh 2003-04-17 6:09 ` Anton Farygin 2003-04-17 7:32 ` Ed V. Bartosh 2003-04-17 8:48 ` Anton Farygin 2003-04-17 8:49 ` Ed V. Bartosh 2003-04-17 10:14 ` Anton Farygin 2003-04-17 10:34 ` Ed V. Bartosh 2003-04-17 12:09 ` Anton Farygin 2003-04-17 11:56 ` Ed V. Bartosh 2003-04-17 13:14 ` Peter Novodvorsky 2003-04-17 10:57 ` aen 2003-04-17 13:16 ` Dmitry V. Levin 2003-04-17 12:36 ` Ed V. Bartosh 2003-04-17 13:12 ` Peter Novodvorsky 2003-04-17 13:24 ` Ed V. Bartosh 2003-04-17 14:41 ` aen 2003-04-17 14:18 ` aen 2003-04-17 10:49 ` Dmitry V. Levin 2003-04-17 10:58 ` [JT] " Anton Farygin 2003-04-17 10:50 ` Ed V. Bartosh 2003-04-17 12:11 ` Anton Farygin 2003-04-17 11:22 ` Dmitry V. Levin 2003-04-17 11:21 ` Anton Farygin 2003-04-24 23:59 ` Michael Shigorin 2003-04-17 10:43 ` Dmitry V. Levin 2003-04-17 10:16 ` Ed V. Bartosh 2003-04-17 13:09 ` Dmitry V. Levin 2003-04-17 12:25 ` Ed V. Bartosh 2003-04-24 23:57 ` Michael Shigorin 2003-04-25 9:35 ` Ed V. Bartosh 2003-04-25 10:41 ` Michael Shigorin 2003-04-25 9:45 ` Ed V. Bartosh 2003-04-25 12:04 ` Michael Shigorin 2003-04-25 11:17 ` Ed V. Bartosh 2003-04-25 13:26 ` Michael Shigorin 2003-04-25 14:34 ` Ed V. Bartosh 2003-04-16 7:44 ` Ed V. Bartosh [this message] 2003-04-16 9:28 ` aen 2003-04-16 8:58 ` Ed V. Bartosh 2003-04-16 10:08 ` Peter Novodvorsky 2003-04-16 10:39 ` aen 2003-04-16 10:31 ` Ed V. Bartosh 2003-04-16 9:36 ` Dmitry V. Levin 2003-04-16 10:13 ` Sergey Bolshakov 2003-04-16 10:45 ` aen 2003-04-16 10:01 ` Peter Novodvorsky 2003-04-16 10:15 ` Ed V. Bartosh 2003-04-16 22:10 ` Dmitry V. Levin 2003-04-17 7:21 ` Ed V. Bartosh 2003-04-17 9:21 ` aen 2003-04-17 9:35 ` Peter Novodvorsky 2003-04-17 10:47 ` Ed V. Bartosh 2003-04-17 11:29 ` Dmitry V. Levin 2003-04-17 11:36 ` Sergey Pinaev 2003-04-17 11:55 ` aen 2003-04-15 16:14 ` aen 2003-04-15 16:35 ` [d-kernel] " Vitaly Ostanin 2003-04-15 18:29 ` Peter Novodvorsky 2003-04-15 16:46 ` [d-kernel] " aen 2003-04-16 0:32 ` Denis Smirnov 2003-04-16 2:48 ` Albert R. Valiev 2003-04-16 7:47 ` Ed V. Bartosh 2003-04-16 9:28 ` aen 2003-04-16 8:47 ` aen 2003-04-16 8:42 ` Albert R. Valiev 2003-04-25 0:13 ` Michael Shigorin 2003-04-25 6:12 ` Sviatoslav Sviridov/Lintec Project 2003-04-25 6:41 ` Albert R. Valiev 2003-04-25 6:58 ` Sviatoslav Sviridov/Lintec Project 2003-04-25 6:59 ` Albert R. Valiev 2003-04-16 10:26 ` [d-kernel] " Vitaly Ostanin 2003-04-17 11:34 ` [d-kernel] " 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=m3znmqevj8.fsf@sam-solutions.net \ --to=ed@sam-solutions.net \ --cc=devel-kernel@altlinux.ru \ /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 kernel packages development This inbox may be cloned and mirrored by anyone: git clone --mirror http://lore.altlinux.org/devel-kernel/0 devel-kernel/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-kernel devel-kernel/ http://lore.altlinux.org/devel-kernel \ devel-kernel@altlinux.org devel-kernel@altlinux.ru devel-kernel@altlinux.com public-inbox-index devel-kernel Example config snippet for mirrors. Newsgroup available over NNTP: nntp://lore.altlinux.org/org.altlinux.lists.devel-kernel AGPL code for this site: git clone https://public-inbox.org/public-inbox.git