[devel] Re: new task proposal policy

Igor Zubkov =?iso-8859-1?q?icesik_=CE=C1_mail=2Eru?=
Вт Июл 5 03:28:30 MSD 2005


В сообщении от Понедельник, 04-Июл-2005 17:43 Michael Shigorin написал(a):
> On Thu, Jun 30, 2005 at 03:40:42AM +0300, Igor Zubkov wrote:
> > Реализация (на примере kde и xmms): 1) Создаётся пакет
> > с именем начинающимся с "task-". К примеру - task-kde-full
> > и task-xmms-full. В зависимостях только список пакетов.
>
> Кстати... имеет ли смысл разделить /задачи/ и /кластеры пакетов/?

Я думал -- что я забыл? Это то!

Действительно поделить это всё таким образом.

> Task (англ.) -- задача.  По крайней мере xmms -- не "задача",
> а "средство".  "Задача", в которую может входить такой
> install-xmms-full -- скажем, task-media-sound.

Разумно.

> Бишь тут речь о /кластерах/ пакетов, а не задачах как таковых.
> Например, k3b-full больше похож на /задачу/ постольку, поскольку
> подтягивает предполагаемые пакеты.

С k3b я с тобой не соглашусь. Это надо очень сильно поломать мозги что бы так 
думать. Пользователь (самый обычный) будет сильно  удивлён тем что мета пакет 
для установки k3b (всего k3b со всеми феньками) запихнут в "Задачи". Или я не 
прав?

> Вообще в Debian[1] и разных репозиториях[2] это всё сваливается
> в tasks, но что-то подсказывает, что разделение ориентированных
> на пакеты и задачи "группирователей" может помочь в дальнейшем
> при создании модуля alterator-tasks (или в alterator-packages)
> и особенно при использовании -- не замусоривая пользовательские
> вещи техническими.

Угу.

> > 2) Создаётся группа в rpm -- "Tasks"/"Задачи" где будут "жить"
> > все эти пакеты.
>
> BTW, есть мнение[3], что таким пакетам может быть место
> в отдельной компоненте репозитория.

Под репозиторий т.е.? Типа RPMS.tasks и SRPMS.tasks?

> > В итоге мы получим: Все виртуальные пакеты лежат в одной
> > группе. Их не придётся искать по всем группа и думать "а куда
> > сегодня разработчики его положили?". Или "а как мне поставить
> > всё kde и всё что под него есть одной командой?".
>
> Угу.  Но всё-таки давайте оставим task-* для _задач_ -- потому

Ок. task-* для задач.

> как "task-kde" может включать "install-kde-full" и ещё чего по

Гм... теряю мысль -- что может тогда содержать пакет task-kde?

Я могу себе представить что может содержать пакет task-kde-devel -- это 
зависимости на gcc, gcc-c++, libqt-devel, kdelibs-devel и kdebase-devel. Т.е. 
всё что нужно для разработки приложений для и под KDE.

> мелочам, а "task-gateway" -- squid, mrtg и ещё чего там.

Разумно! По крайней мере maintainer мифического пакета (мифического -- потому 
что его ещё нет) "task-webserver" может запихнуть в него всё что может 
потребоватся для жизни админу webserver'a. И админу не надо парится и искать 
-- а как называются пакеты с web сервером и модулями под него и так далее...

> PS: могу усложнять жизнь сверх необходимости, в каковом случае
> сообщение можно игнорировать :)

Нормально! ;-) Никому кроме себя мы жизнь не усложним т.к. на простых 
пользователях это всё сейчас не отражается. У них стоит Мастер 2.4 где всего 
этого просто нет. ;-) А если у них не Мастер, то они уже явно не простые 
пользователи ;-)

> References
> ~~~~~~~~~~
> [1] http://www.us.debian.org/doc/debian-policy/ch-binary.html#s3.9
> [2]
> http://lists.freshrpms.net/pipermail/freshrpms-list/2002-May/001000.html
> [3]
> http://distro.conectiva.com.br/pipermail/apt-rpm/2002-October/000829.html

Почитаю, только не сейчас -- пора спать!

Да, кстати, если уж резать на "Задачи"/"Tasks" и "install", то как обозвать 
эту группу в rpm?

Куда проще свалить это всё в кучу -- вот только это будет помойка, а помойка 
никому не нужна.



Подробная информация о списке рассылки Devel