From: "Evgeny Sinelnikov" <sin@altlinux.ru> To: "ALT Linux Team development discussions" <devel@lists.altlinux.org> Subject: Re: [devel] Десктоп и высокоуровневое управление пакетами Date: Sat, 1 Mar 2008 00:28:01 +0300 Message-ID: <921f6bb40802291328x4f433d1drc1fe9b8ac2e2f161@mail.gmail.com> (raw) In-Reply-To: <20080229141312.94f1d6a9.boyarsh@altlinux.org> Здравствуйте. 2008/2/29 Anton V. Boyarshinov <boyarsh@altlinux.org>: > Доброе время суток > > На сегодняшний день в десктопных дистрибутивах ALT Linux имеются значительные (по крайней мере для "простого" пользователя) проблемы с установкой/удалением пакетов, как в процессе установки, так и позже. > > Сразу замечу, что выбор основанный на rpm пакетах я считаю неприемлимым для всех, не являющихся linux гуру, так как их количество весьма велико и смысл большинства из них непонятен пользователям (а оперировать огромным и почти не понятным списком невозможно). > > ============================ > Начну с простого: с установки. Выбор групп, предоставляемый установщикам слишком общий и в результате пользователь в большинстве случаев получает систему и меню, захламлённую программами. Программами, безусловно, полезными, но не каждому. > > Возможные решения: > Фиксирование меню как в Юниоре. Но это влечёт за собой то, что всё, что пользователь поставит дополнительно (а это наверняка будут нужные ему программы), окажется в "дополнительных приложениях", что не очень удобно. > > Введение второго уровня подробности в выбор дополнительных пакетов при установке (не попакетного выбора, но выбора тех или иных частей больших групп пакетов, например "Сеть:браузер/почтовый клиент/файлообмен/irc/usenet/телефония"). Достаточно легко реализуется. > Не могу полностью полностью согласиться, что все программы в меню - это захламление, хотя в Юниоре, как вы говорите, меню зафиксировано из этих же соображений. Относительно же установки, большинству пользователей не свойственно помнить заранее весь список программ, который им может понадобиться. Здесь стоит подумать об удобстве во втором пункте. Согласен с тем, что попакетный выбор не удобен. Возможность выбора выбора по пакетам, обычно только усложняет процесс - все нужные программы не переберёшь, наугад не вспомнишь. Выбор по разделам интереснее, но это нужно либо кому-то отдельно отслеживать список пакетов, что может быть интересно в плане формализации и утверждения этого списка: http://freesource.info/wiki/TZ/LinuxDesktop/Sostav, либо заложиться на автоматизацию по некому формальному критерию, что может вызывать побочные эффекты, хотя всё зависит от критерия. > =================================== > Работа с пакетами в установленной системе. > > С одной стороны, у нас есть apt и даже synaptic, а с другой -- у нас почти ничего нет. Несколько раз слышал вопросы "А как это делают простые люди, не такие эксперты?" и мне нечего ответить кроме как "зовут эксперта". Это здорово, но не всегда приемлимо, да и я не выпью столько пива. > > synaptic весьма неспешен на большом количестве пакетов, да и глаза от этих списков разбегаются даже у меня. Фильтрация по RPM группам малоосмысленна (во всяком случае, в нынешнем виде). > > Возможные решения: > Создание дополнительной RPM группы (допустим Meta), которой будут принадлежать исключительно meta-пакеты, при этом отвечающие за установку программ (а не библиотек, утилит) имеющих графический интерфейс (способный управиться с текствовым, управится и с apt) и пригодных к использованию. Пакеты из этой группы обязательно должны иметь переводы описаний в specpo. > > Пропатчить synaptic чтоб он работал только с этой группой (или хотя бы с этой группой по умолчанию) или написать (предположительно на alterator) отдельный инструмент управления пакетами, показывающий пользователю только пакеты из группы Meta (по крайней мере по умолчанию). > > ------------------------- > Создание дополнительной инфраструктуры (возможно, подобной Metadata/pkg-groups) и специального средства для высокоуровневого управления пакетами (предполжительно на alterator). ИМХО критерием для попадания описания пакета в эту инфраструктуру можнет быть наличие в нём desktop файла. > > Второй путь мне нравится больше, но его надо обдумать, чтоб не создать велосипед с 5 колёсами. Дополнительная инфраструктура мне кажется излишней, если уже сейчас можно пропатчить synaptic так, чтобы при отображении списка того, что можно назвать пользовательскими программами отображались только те пакеты, которые содержат хотя бы один десктоп-файл. Это можно сделать отдельным пунктом при в выборе группы отображаемых пакетов. Кстати, какой смысл в дополнительной инфраструктуре, когда этого можно добиться интерпретацией того, что есть. Это же исключительно клиентская часть по отображению. Не стоит ради неё делать дополнитльные усложнения пакетов. Может быть улучшить пользовательское качество самого synaptic'а ? В процессе станет понятно насколько необходимы метапакеты для этой задачи. Кроме того, если ужесточить критерий отбора, можно вместо группы провайдить имена специального вида %name-desktop-application и сортировать по ним... но всё равно это не очень хорошее решение, поскольку можно скачать Acroreader или что-нибудь, а оно ни по группе, ни по провайдингу не попадёт в этот список. -- Sin (Sinelnikov Evgeny)
prev parent reply other threads:[~2008-02-29 21:28 UTC|newest] Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top 2008-02-29 11:13 Anton V. Boyarshinov 2008-02-29 11:23 ` ruslandh 2008-02-29 11:29 ` Anton V. Boyarshinov 2008-02-29 12:08 ` ruslandh 2008-02-29 12:13 ` Igor Vlasenko 2008-02-29 12:24 ` Anton V. Boyarshinov 2008-02-29 12:59 ` Alex Myltsev 2008-02-29 14:24 ` Андрей Черепанов 2008-02-29 14:37 ` Anton V. Boyarshinov 2008-02-29 14:41 ` Mikhail Gusarov 2008-02-29 14:42 ` Anton Farygin 2008-02-29 14:44 ` Mikhail Gusarov 2008-02-29 14:54 ` Anton Farygin 2008-02-29 15:00 ` Anton V. Boyarshinov 2008-02-29 15:19 ` Anton Farygin 2008-02-29 15:31 ` Андрей Черепанов 2008-02-29 16:39 ` Igor Vlasenko 2008-02-29 14:06 ` Slava Dubrovskiy 2008-02-29 20:52 ` Alexey Rusakov 2008-03-03 12:49 ` Michael Shigorin 2008-02-29 14:22 ` Андрей Черепанов 2008-02-29 21:28 ` Evgeny Sinelnikov [this message]
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=921f6bb40802291328x4f433d1drc1fe9b8ac2e2f161@mail.gmail.com \ --to=sin@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