[devel] new task proposal policy

[devel] new task proposal policy

[Igor Zubkov]

Привет, Всем!

После того как я сегодня не нашёл в Сизифе пакета kde-maxi (месяц назад ещё 
был ;-) ) я решил предложить полиси по поводу виртуальных пакетов которые 
тянут за собой много пакетов. Ну как пакет kde-maxi который тянул за собой 
кроме всего kde ещё и все остальные qt/kde приложения.

Цель - стандартизировать нахождение и установку всего и вся.

Реализация (на примере kde и xmms):
1) Создаётся пакет с именем начинающимся с "task-". К примеру - task-kde-full 
и task-xmms-full. В зависимостях только список пакетов.

2) Создаётся группа в rpm -- "Tasks"/"Задачи" где будут "жить" все эти пакеты.

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

Поддержку пакета task-kde-full я беру на себя ;-)

Ну и просто мелочь -- запретить пихать такие пакеты в BuildRequires. Это что 
бы не было лишнего оверхэда в сборочной среде и зависимостях.

Примеры:
1) Спек для task-kde-full.spec:
Name: task-kde-full
Version: 3.4.1

Summary: Virtual package to install all KDE and all KDE/Qt applications
Summary(ru_RU.KOI8-R): Виртуальный пакет для установки всего KDE и всех KDE/Qt 
приложений
License: free
Group: Tasks

Requires: arts
Requires: kdelibs
Requires: kdebase
Requires: kdepim
Requires: kdenetwork
Requires: kdeartwork
Requires: kdegames
Requires: kdeadmin
Requires: kdeutils
Requires: kdeaccessibility
Requires: kdeaddons
Requires: kdeedu
Requires: kdegraphics
Requires: kdemultimedia
Requires: kdesdk
Requires: kdetoys
Requires: kdevelop
Requires: kdewebdev

Requires: koffice

Requires: kdebluetooth
Requires: kdetv
Requires: kdiff3
Requires: kftpgrabber
Requires: kile
Requires: kink
Requires: kiso
Requires: kkbswitch
Requires: klamav
Requires: kmencoder
Requires: kmobiletools
Requires: kpacman
Requires: kplayer
Requires: krename
Requires: krusader
Requires: ksystemlog - Displays and analyze system logfiles
Requires: ktraynetworker - KDE tray icon Network activity monitor
Requires: kuake
Requires: showimg
Requires: sim
Requires: smb4k
Requires: superkaramba
Requires: synce-kde
Requires: apollon
Requires: apt-indicator
Requires: digikam
Requires: gwenview
Requires: kaffeine
Requires: kamix
Requires: kasablanca
Requires: kbirthday
Requires: kcpuload 

%description
This is virtual package. It doesn't contents any files but it contents depends 
on it. Install this packages if you want all KDE with all KDE/Qt 
applications.

%description -l ru_RU.KOI8-R
Это виртуальный пакет. Он не содержит никаких файлов, но он содержит 
зависимости на них. Поставьте этот пакет если вам необходимо все KDE и все 
прилодежия под него.

%files

%changelog

Примерно таким же образом можно сделать спек для task-kde-full-devel...

Список зависомостей для task-xmms-full (примерный)
xmms
xmms-in-flac
xmms-in-mad
xmms-in-vorbis
xmms-in-wma
xmms-out-nas
xmms-out-esd
xmms-out-alsa
xmms-out-arts
и так далее...

Ну и напоследок охота сказать что в conectiva было сделано так же.

Re: [devel] new task proposal policy

[Sergey V Turchin]

[-- Attachment #1: Type: text/plain, Size: 400 bytes --]

В сообщении от Четверг 30 Июнь 2005 04:40 Igor Zubkov написал(a):

[...]

> Поддержку пакета task-kde-full
Такого пакета не бывает в принципе. См. архивы.

> я беру на себя ;-)
task-kde-maxi - отдам с удовольствием.
Если хотите - task-kde-maximum
kde-big и меньше - не отдам.

-- 
Regards, Sergey, ALT Linux Team, http://www.altlinux.ru
http://stinkfoot.org:11371/pks/lookup?op=get&search=0x1C2A3F08

[-- Attachment #2: Type: application/pgp-signature, Size: 190 bytes --]

Re: [devel] new task proposal policy

[Alexander Bokovoy]

[-- Attachment #1: Type: text/plain, Size: 636 bytes --]

On Mon, Jul 04, 2005 at 01:07:07PM +0400, Sergey V Turchin wrote:
> В сообщении от Четверг 30 Июнь 2005 04:40 Igor Zubkov написал(a):
> 
> [...]
> 
> > Поддержку пакета task-kde-full
> Такого пакета не бывает в принципе. См. архивы.
> 
> > я беру на себя ;-)
> task-kde-maxi - отдам с удовольствием.
> Если хотите - task-kde-maximum
> kde-big и меньше - не отдам.
Тогда хотя бы переименуй их в task-kde-big и меньше.

-- 
/ Alexander Bokovoy
Samba Team                      http://www.samba.org/
ALT Linux Team                  http://www.altlinux.org/
Midgard Project Ry              http://www.midgard-project.org/

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] new task proposal policy

[Sergey V Turchin]

[-- Attachment #1: Type: text/plain, Size: 315 bytes --]

В сообщении от Понедельник 04 Июль 2005 14:12 Alexander Bokovoy 
написал(a):

[...]

> > kde-big и меньше - не отдам.
>
> Тогда хотя бы переименуй их в task-kde-big и меньше.
Provides сделаю

-- 
Regards, Sergey, ALT Linux Team, http://www.altlinux.ru
http://stinkfoot.org:11371/pks/lookup?op=get&search=0x1C2A3F08

[-- Attachment #2: Type: application/pgp-signature, Size: 190 bytes --]

[devel] Re: new task proposal policy

[Michael Shigorin]

On Mon, Jul 04, 2005 at 02:58:05PM +0400, Sergey V Turchin wrote:
> > > kde-big и меньше - не отдам.
> > Тогда хотя бы переименуй их в task-kde-big и меньше.
> Provides сделаю

Не, лучше переименовать и в RPMS.task (если глупостев рядом
не наговорил и люди неспроста выносят такое отдельно).

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

Re: [devel] Re: new task proposal policy

[Sergey V Turchin]

[-- Attachment #1: Type: text/plain, Size: 544 bytes --]

В сообщении от Понедельник 04 Июль 2005 18:45 Michael Shigorin 
написал(a):
> On Mon, Jul 04, 2005 at 02:58:05PM +0400, Sergey V Turchin wrote:
> > > > kde-big и меньше - не отдам.
> > >
> > > Тогда хотя бы переименуй их в task-kde-big и меньше.
> >
> > Provides сделаю
>
> Не, лучше переименовать и в RPMS.task (если глупостев рядом
> не наговорил и люди неспроста выносят такое отдельно).
Тогда это про другие пакеты.

-- 
Regards, Sergey, ALT Linux Team, http://www.altlinux.ru
http://stinkfoot.org:11371/pks/lookup?op=get&search=0x1C2A3F08

[-- Attachment #2: Type: application/pgp-signature, Size: 190 bytes --]

[devel] Re: new task proposal policy

[Michael Shigorin]

[-- Attachment #1: Type: text/plain, Size: 597 bytes --]

On Mon, Jul 04, 2005 at 07:58:32PM +0400, Sergey V Turchin wrote:
> > > > > kde-big и меньше - не отдам.
> > > > Тогда хотя бы переименуй их в task-kde-big и меньше.
> > > Provides сделаю
> > Не, лучше переименовать и в RPMS.task (если глупостев рядом
> > не наговорил и люди неспроста выносят такое отдельно).
> Тогда это про другие пакеты.

Собсно потому и предложение про install-* с соотв. полиси (для
"технических кучек" пакетов и в classic) и task-* -- для "задач" 
и отдельно.

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] new task proposal policy

[Yury Aliaev]

Hi, Igor!

> и task-xmms-full. В зависимостях только список пакетов.

Что касается xmms, то в Сизифе давно сидят xmms-full, -normal и 
-minimal. Если появится группа "Tasks", то повесьте, пожалуйста, багу на 
какой-нибудь из этих пакетов, и я их соответствующим образом переделаю.

[devel] Re: new task proposal policy

[Michael Shigorin]

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 больше похож на /задачу/ постольку, поскольку
подтягивает предполагаемые пакеты.

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

> 2) Создаётся группа в rpm -- "Tasks"/"Задачи" где будут "жить"
> все эти пакеты.

BTW, есть мнение[3], что таким пакетам может быть место
в отдельной компоненте репозитория.

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

Угу.  Но всё-таки давайте оставим task-* для _задач_ -- потому
как "task-kde" может включать "install-kde-full" и ещё чего по
мелочам, а "task-gateway" -- squid, mrtg и ещё чего там.

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

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

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

Re: [devel] Re: new task proposal policy

[Igor Zubkov]

В сообщении от Понедельник, 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?

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

Re: [devel] Re: new task proposal policy

[Andrey Rahmatullin]

[-- Attachment #1: Type: text/plain, Size: 943 bytes --]

On Tue, Jul 05, 2005 at 02:28:30AM +0300, Igor Zubkov wrote:
> > Например, k3b-full больше похож на /задачу/ постольку, поскольку
> > подтягивает предполагаемые пакеты.
> С k3b я с тобой не соглашусь. Это надо очень сильно поломать мозги что бы так 
> думать. Пользователь (самый обычный) будет сильно  удивлён тем что мета пакет 
> для установки k3b (всего k3b со всеми феньками) запихнут в "Задачи". Или я не 
> прав?
Ребят, забейте на k3b.

* Срд Фев 16 2005 Alexey Lokhin <warframe@altlinux> 0.11.20-alt1
- Package 'k3b-minimal' has been combined with 'k3b'


-- 
WBR, wRAR (ALT Linux Team)
Powered by the ALT Linux fortune(8):

Это, наверное, не всем интересно.  talk-room в этом смысле -- странная
штука.  Каждый пишет совершенно про своё, в поисках потенциальной
аудитории.  Что у кого болит, тот о том и говорит.  Тут дьявол с Богом
борется, и далее по тексту.  Надо с этим что-то делать...
		-- at in talk-room@

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

[devel] Re: new task proposal policy

[Michael Shigorin]

On Tue, Jul 05, 2005 at 02:28:30AM +0300, Igor Zubkov wrote:
> > Бишь тут речь о /кластерах/ пакетов, а не задачах как
> > таковых.  Например, k3b-full больше похож на /задачу/
> > постольку, поскольку подтягивает предполагаемые пакеты.
> С k3b я с тобой не соглашусь. Это надо очень сильно поломать
> мозги что бы так думать. Пользователь (самый обычный) будет
> сильно  удивлён тем что мета пакет для установки k3b (всего k3b
> со всеми феньками) запихнут в "Задачи". Или я не прав?

Я тоже посомневался, но решил отправить письмо, а не откладывать
на утро.  Которое не только мудреней, но и сонное %)

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

Угу.  Я ещё попробую узнать, почему в разных местах, включая
Debian, их именно что выносят из основного "лежбища", но вряд ли
безосновательно...

> > как "task-kde" может включать "install-kde-full" и ещё чего по
> Гм... теряю мысль -- что может тогда содержать пакет task-kde?

Софт, который не входит в KDE, но зело приятен.  Сходу не
соображу (сам на WM), но для task-gnome напрашивается gkrellm,
наверное.

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

Кстати, да.

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

Или "поставить, лишнее снести".  Не оптимальный, но порой самый
быстрый вариант, когда исходные требования "плавают".

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

Install/Установка, вестимо.

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

Re: [devel] Re: new task proposal policy

[Alexey Rusakov]

Michael Shigorin wrote:

>>>как "task-kde" может включать "install-kde-full" и ещё чего по
>>>      
>>>
>>Гм... теряю мысль -- что может тогда содержать пакет task-kde?
>>    
>>
>
>Софт, который не входит в KDE, но зело приятен.  Сходу не
>соображу (сам на WM), но для task-gnome напрашивается gkrellm,
>наверное.
>  
>
А также GIMP, Grip, StarDict, GNOME Configurator... :) Строго говоря, 
для Grip, StarDict и GKrellM в самом GNOME есть альтернативы. В общем, 
иногда бывает не совсем понятно, достаточно ли "приятен" софт, чтобы 
быть включённым в список избранных в task-* пакет.

-- 
  Alexey "Ktirf" Rusakov

Re: [devel] Re: new task proposal policy

[Slava Dubrovskiy]

Michael Shigorin пишет:

>>Реализация (на примере kde и xmms): 1) Создаётся пакет
>>с именем начинающимся с "task-". К примеру - task-kde-full
>>и task-xmms-full. В зависимостях только список пакетов.
>>    
>>
Вот если бы еще создавать пакет, который бы делал совершенно
противоположное - удалял все (включая библиотеки). А то apt-get remove
-D не всегда все удаляет.

-- 
С уважением,
Дубровский Вячеслав.

[devel] Re: Re: new task proposal policy

[Anton Farygin]

В письме Tue, 05 Jul 2005 10:06:19 +0300, Slava Dubrovskiy
написал:

> Michael Shigorin пишет:
> 
>>>Реализация (на примере kde и xmms): 1) Создаётся пакет
>>>с именем начинающимся с "task-". К примеру - task-kde-full
>>>и task-xmms-full. В зависимостях только список пакетов.
>>>    
>>>
> Вот если бы еще создавать пакет, который бы делал совершенно
> противоположное - удалял все (включая библиотеки). А то apt-get remove
> -D не всегда все удаляет.

Патчи на apt-get приветствуются.

Rgds,
Rider

[devel] Re: new task proposal policy

[Michael Shigorin]

On Tue, Jul 05, 2005 at 10:06:19AM +0300, Slava Dubrovskiy wrote:
> >>Реализация (на примере kde и xmms): 1) Создаётся пакет
> >>с именем начинающимся с "task-". К примеру - task-kde-full
> >>и task-xmms-full. В зависимостях только список пакетов.
> Вот если бы еще создавать пакет, который бы делал совершенно
> противоположное - удалял все (включая библиотеки). А то apt-get
> remove -D не всегда все удаляет.

Технически это можно сделать при помощи Conflicts:, но IMCO
разумней копать в сторону автосмотрелки-кто-из-пакетов-валяется
(в смысле чьи файлы давно не трогались).  В демьяне нечто такое
было, но спортировать в полпинка не вышло (как и popularity
contest).

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

[devel] Re: new task proposal policy

[Anton Farygin]

В письме Tue, 05 Jul 2005 10:15:20 +0300, Michael Shigorin
написал:

> On Tue, Jul 05, 2005 at 10:06:19AM +0300, Slava Dubrovskiy wrote:
>> >>Реализация (на примере kde и xmms): 1) Создаётся пакет
>> >>с именем начинающимся с "task-". К примеру - task-kde-full
>> >>и task-xmms-full. В зависимостях только список пакетов.
>> Вот если бы еще создавать пакет, который бы делал совершенно
>> противоположное - удалял все (включая библиотеки). А то apt-get
>> remove -D не всегда все удаляет.
> 
> Технически это можно сделать при помощи Conflicts:, но IMCO
> разумней копать в сторону автосмотрелки-кто-из-пакетов-валяется
> (в смысле чьи файлы давно не трогались).  В демьяне нечто такое
> было, но спортировать в полпинка не вышло (как и popularity
> contest).

IMHO это можно все реализовать на другом, не пакетном уровне.

Для примера - смотрите профили
(alterator-packages) в installer-2.9.10.iso.

Так будет правильнее, проще и надежнее IMHO.

Rgds,
Rider

Re: [devel] Re: new task proposal policy

[Slava Dubrovskiy]

Anton Farygin пишет:

>>>Вот если бы еще создавать пакет, который бы делал совершенно
>>>противоположное - удалял все (включая библиотеки). А то apt-get
>>>remove -D не всегда все удаляет.
>>>      
>>>
>>Технически это можно сделать при помощи Conflicts:, но IMCO
>>разумней копать в сторону автосмотрелки-кто-из-пакетов-валяется
>>(в смысле чьи файлы давно не трогались).  В демьяне нечто такое
>>было, но спортировать в полпинка не вышло (как и popularity
>>contest).
>>    
>>
>IMHO это можно все реализовать на другом, не пакетном уровне.
>Для примера - смотрите профили
>(alterator-packages) в installer-2.9.10.iso.
>Так будет правильнее, проще и надежнее IMHO.
>  
>
Ну тогда и зачем заморачиваться с этими task?

-- 
С уважением,
Дубровский Вячеслав.

[devel] Re: new task proposal policy

[Michael Shigorin]

On Tue, Jul 05, 2005 at 10:32:49AM +0300, Slava Dubrovskiy wrote:
> Ну тогда и зачем заморачиваться с этими task?

Гм.  Ну раскопайте историю развития tasksel тогда и рассказывайте :)

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

Re: [devel] Re: new task proposal policy

[Slava Dubrovskiy]

Michael Shigorin пишет:

>>Ну тогда и зачем заморачиваться с этими task?
>>    
>>
>Гм.  Ну раскопайте историю развития tasksel тогда и рассказывайте :)
>  
>
Просто действительно не логично. Как установить, так через apt-get
install task-* А как удалить, так через другой механизм. Получается что
предлагаемый механизм (через task) не совершенен? И есть более гибкое
решение (профили)? Думаю, что если профили справятся с удалением, то уж
с установкой и подавно.
А кстати, в дружелюбной системе для пользователя, удалить даже важнее
чем установить (чаще написано как установить). Я вспоминаю, когда я
только начинал изучать линукс, как трудно было вернуть все обратно после
многочисленных экспериментов :-)

-- 
С уважением,
Дубровский Вячеслав.

[devel] Re: Re: new task proposal policy

[Anton Farygin]

В письме Tue, 05 Jul 2005 10:54:21 +0300, Slava Dubrovskiy
написал:

> Michael Shigorin пишет:
> 
>>>Ну тогда и зачем заморачиваться с этими task?
>>>    
>>>
>>Гм.  Ну раскопайте историю развития tasksel тогда и рассказывайте :)
>>  
>>
> Просто действительно не логично. Как установить, так через apt-get
> install task-* А как удалить, так через другой механизм. Получается что
> предлагаемый механизм (через task) не совершенен? И есть более гибкое
> решение (профили)? Думаю, что если профили справятся с удалением, то уж
> с установкой и подавно.
> А кстати, в дружелюбной системе для пользователя, удалить даже важнее
> чем установить (чаще написано как установить). Я вспоминаю, когда я
> только начинал изучать линукс, как трудно было вернуть все обратно после
> многочисленных экспериментов :-)

А вот с удалением у профилей такая же беда как и у apt'а.

IMHO тут все-таки придется патчить apt-get (apt-shell)

Rgds,
Rider

[devel] Re: new task proposal policy

[Michael Shigorin]

On Tue, Jul 05, 2005 at 11:26:03AM +0400, Anton Farygin wrote:
> IMHO это можно все реализовать на другом, не пакетном уровне.

Тоже правда.

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

Re: [devel] Re: new task proposal policy

[Alexander Bokovoy]

[-- Attachment #1: Type: text/plain, Size: 889 bytes --]

On Tue, Jul 05, 2005 at 11:26:03AM +0400, Anton Farygin wrote:
> > Технически это можно сделать при помощи Conflicts:, но IMCO
> > разумней копать в сторону автосмотрелки-кто-из-пакетов-валяется
> > (в смысле чьи файлы давно не трогались).  В демьяне нечто такое
> > было, но спортировать в полпинка не вышло (как и popularity
> > contest).
> 
> IMHO это можно все реализовать на другом, не пакетном уровне.
> 
> Для примера - смотрите профили
> (alterator-packages) в installer-2.9.10.iso.
> 
> Так будет правильнее, проще и надежнее IMHO.
Еще не смотрел, но раз уж это делается снаружи, то механика "мягких"
зависимостей и рекомендаций в такой системе бы не помешала.
-- 
/ Alexander Bokovoy
Samba Team                      http://www.samba.org/
ALT Linux Team                  http://www.altlinux.org/
Midgard Project Ry              http://www.midgard-project.org/

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

[devel] Re: Re: new task proposal policy

[Anton Farygin]

В письме Tue, 05 Jul 2005 15:41:36 +0400, Alexander Bokovoy
написал:

> On Tue, Jul 05, 2005 at 11:26:03AM +0400, Anton Farygin wrote:
>> > Технически это можно сделать при помощи Conflicts:, но IMCO
>> > разумней копать в сторону автосмотрелки-кто-из-пакетов-валяется
>> > (в смысле чьи файлы давно не трогались).  В демьяне нечто такое
>> > было, но спортировать в полпинка не вышло (как и popularity
>> > contest).
>> 
>> IMHO это можно все реализовать на другом, не пакетном уровне.
>> 
>> Для примера - смотрите профили
>> (alterator-packages) в installer-2.9.10.iso.
>> 
>> Так будет правильнее, проще и надежнее IMHO.
> Еще не смотрел, но раз уж это делается снаружи, то механика "мягких"
> зависимостей и рекомендаций в такой системе бы не помешала.

О чем и речь. Пока что там нет ничего
кроме рекомендуемых к установке групп.
Но развиваться IMHO стоит именно в этом направлении.

Rgds,
Rider

Re: [devel] Re: new task proposal policy

[Yury Aliaev]

Michael Shigorin пишет:
> 
>>Реализация (на примере kde и xmms): 1) Создаётся пакет
>>с именем начинающимся с "task-". К примеру - task-kde-full
>>и task-xmms-full. В зависимостях только список пакетов.
> 
> 
> Кстати... имеет ли смысл разделить /задачи/ и /кластеры пакетов/?
> 
> Task (англ.) -- задача.  По крайней мере xmms -- не "задача",
> а "средство".  "Задача", в которую может входить такой
> install-xmms-full -- скажем, task-media-sound.
> 
> Бишь тут речь о /кластерах/ пакетов, а не задачах как таковых.
> Например, k3b-full больше похож на /задачу/ постольку, поскольку
> подтягивает предполагаемые пакеты.

[...]

Мысля, однако, хорошая... Я вечером, когда домой ехал, вообще решил, что 
можно для начала всё такое свалить в группу "virtual", не заморачиваясь 
особенно, task ли это или claster.

Re: [devel] Re: new task proposal policy

[vserge]

Приветсвую

On Mon, 4 Jul 2005 17:43:20 +0300
Michael Shigorin <mike@osdn.org.ua> wrote:

> On Thu, Jun 30, 2005 at 03:40:42AM +0300, Igor Zubkov wrote:
> > Реализация (на примере kde и xmms): 1) Создаётся пакет
> > с именем начинающимся с "task-". К примеру - task-kde-full
> > и task-xmms-full. В зависимостях только список пакетов.
> 
> Кстати... имеет ли смысл разделить /задачи/ и /кластеры пакетов/?
> 
[skip]
> > В итоге мы получим: Все виртуальные пакеты лежат в одной
> > группе. Их не придётся искать по всем группа и думать "а куда
> > сегодня разработчики его положили?". Или "а как мне поставить
> > всё kde и всё что под него есть одной командой?".
> 
> Угу.  Но всё-таки давайте оставим task-* для _задач_ -- потому
> как "task-kde" может включать "install-kde-full" и ещё чего по
> мелочам, а "task-gateway" -- squid, mrtg и ещё чего там.
> 
[skip]

Ко всему выше и ниже сказанному мне хотелось бы добавить свои "две
копейки":
 Есть две взаимно противоположные процедуры "установка" и "удаление"

Так вот сейчас активно обсуждается только первая из них, но хотелось бы
не забывать, что когда у пользователя появляется возможность поставить
некий объем программ (пакетов)  этот "ОБЪЕМ" нужно иметь возможность
также легко удалить его из системы.

Насколько я понимаю данная операция возможно только в случае, если
пользователь дает команду
apt-get -D remove task-taskname

Поэтому нам либо в документации на пакеты task-* надо будет указывать
как удалять их и связанные с ними пакеты, либо проработать вопрос
корректной процедуры удаления



 -- 

[devel] package profiles (was: new task proposal policy)

[Michael Shigorin]

On Wed, Jul 06, 2005 at 10:26:03AM +0400, vserge wrote:
> Поэтому нам либо в документации на пакеты task-* надо будет
> указывать как удалять их и связанные с ними пакеты, либо
> проработать вопрос корректной процедуры удаления

Кажется, в sisyphus@ и/или bugzilla по alterator-packages Антон
чего-то писал по этому поводу.  Я в package profiles ещё толком
не въехал, поэтому пока пас.

2 lioka: в 2.9.11 удаление группы (даблклик по e.g. Hardware) 
не приводит к видимым последствиям, но пакеты, принадлежащие
группе, помечает на вынос.  Повесить или trivial?

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

[devel] Re: package profiles (was: new task proposal policy)

[Anton Farygin]

В письме Thu, 07 Jul 2005 13:44:48 +0300, Michael Shigorin
написал:

> On Wed, Jul 06, 2005 at 10:26:03AM +0400, vserge wrote:
>> Поэтому нам либо в документации на пакеты task-* надо будет
>> указывать как удалять их и связанные с ними пакеты, либо
>> проработать вопрос корректной процедуры удаления
> 
> Кажется, в sisyphus@ и/или bugzilla по alterator-packages Антон
> чего-то писал по этому поводу.  Я в package profiles ещё толком
> не въехал, поэтому пока пас.
> 
> 2 lioka: в 2.9.11 удаление группы (даблклик по e.g. Hardware) 
> не приводит к видимым последствиям, но пакеты, принадлежащие
> группе, помечает на вынос.  Повесить или trivial?

Висит уже 

и совсем не trivial.

Rgds,
Rider