Re: package hierarchy system
Ivan Borzenkov writes:
> This document covers very useful improvement of Debian apt system - the
> package hierarchy system. This system can help end user make it's difficult
> choice which packet he have to install. The main feature is to hide
> unnecessary packages to concentrate user's attention on applications
> itself.
>
> For now apt system have no the application concept, only package one. Some
> packs. are applications, others are plugins for applications or just
> libraries providing some functionality. There are also "-common" packs.
> which concentrates common components.
>
> There are a lot of such packs. For example the quantity of libs is a bit
> more then one third an there a lot of plugins. In general the ordinary
> user don't have to see more than a half of packs.
>
> There is a subdivision of packs. into categories, for example web-servers
> or multimedia. But it's not enough - such packs. as apache2 or nginx which
> should be installed independently are in the same level with
> libapache2-mod-bt and libapache2-mod-geoip, which are not apliable without
> apache2. The web-servers has a good situation, but there is a real
> craziness in administration category for now.
>
> It seems to be good solution to add packs. hierarchy using "parent pointer"
> and service packs. hiding.
> We need information to show this pack. or it's a service pack. and which
> pack. is it's parent or there is no parent.
> The options to hide or to show pack. may be multilevel:
> - show all
> - hide libraries
> - hide debug tools
> ...
> - show applications only
>
> I don't think that the using of pack. type is a good idea as the strict
> link is only one - hide libraries.
>
> Examples
>
> amarok (parent:-, application)
> amarok-common (parent:amapok, hide)
> amarok-utils (parent:amapok, hide)
>
> amarok
> -----------------------------------------------------------
> psi-plis (parent:-, application)
> psi-plis-plugins (parent:psi-plis, mod)
> psimedia (parent:psi-plis, mod)
>
> psi-plis
> - psi-plis-plugins
> - psimedia
> -----------------------------------------------------------
> proftpd (parent:-, application)
> proftpd-doc (parent:proftpd, doc)
> proftpd-mod-ldap (parent:proftpd, mod)
> proftpd-mod-mysql (parent:proftpd, mod)
> proftpd-mod-odbc (parent:proftpd, mod)
> proftpd-mod-pgsql (parent:proftpd, mod)
> proftpd-mod-sqlite (parent:proftpd, mod)
>
> (type grouping possible)
> proftpd
> --docs--
> - proftpd-doc
> --plugins--
> - proftpd-mod-ldap
> - proftpd-mod-mysql
> - proftpd-mod-odbc
> - proftpd-mod-pgsql
> - proftpd-mod-sqlite
> -----------------------------------------------------------
> mysql-server (parent:-, server)
> mysql-server-5.1 (parent:mysql-server, server)
> mysql-server-5.0 (parent:mysql-server, server)
>
> mysql-server
> - mysql-server-5.0
> - mysql-server-5.1
>
> Virtual packet parent have to mark as sub items all who provides it.
>
> Examples
>
> adobe-flashplayer (parent:webbrovser)
>
> opera
> - adobe-flashplayer
> ...
> iceweasel
> - adobe-flashplayer
>
> If unhidden pack. have hidden parent it's parent have to be set to 1-st
> unhidden or by it's dependence.
>
> Examples
>
> libtag-rusxmms (parent: libtag, mod)
> libtag (parent:-, hide)
> amarok (application) (depend on libtag)
>
> amarok
> - libtag-rusxmms
I can see your intentions for improvement, but we already have the concepts of
sections and debtags which are explored by various frontends. Searching and
narrowing down what you were looking for is a heavily supported feature for
both hard core users and mere mortals. Also not that the more hierarchical
means you add, the more stagnancy you got, which is not always a good idea
imho.
--
pub 4096R/0E4BD0AB <people.fccf.net/danchev/key pgp.mit.edu>
Reply to: