This is a transcript of a brainstorming session that is taking place in the debian-devel mailing list.
The goal of the brainstorming is to collect background informations about package managers, like what is a package manager, what is should do, who uses it and to do what. This informations will then be available to be used as a ground for further analyses and in the design of Debian package manager applications.
The readers of this page are welcome to join the brainstorming by sending me a mail
[Osamu Aoki] I think these "User" thing can be summarized in 3 coordinates:
Also "User" may have different focuses:
I think, in the end, in order to address all these different types of user, we need more than menu presentation infrastructures. Something like policy-based configuration tweaking infrastructure especially to address "Skill" things.
At this moment, I think this can be one "User". Debian User :-)
Instead of addressing "User" factors, we may be able to assign "Relevance" attribute of each package for the typical uses.
[Enrico Zini] Maybe this is best addressed by subprojects/metadistros/flavours altogether? I see much potential in that direction.
The main purposes of the package management application are: [Osamu Aoki]
These two main purposes can in turn be decomposed in other subtasks:
[Osamu Aoki] I think "Topics" used by sourceforge is very good starting point for the choice of "Topic". Also "Task" used by Debian is another. See http://people.debian.org/~osamu/pub/osamu-cat.txt for example of these Topics.
Yes, that's a great candidate for a starting task list.
The experience will probably show other tasks not covered in that list (Web CMS and Wireless LAN already come to my mind), and they'll probably come is as bug reports or other feedback. We need to keep a door open for the possibility to fit new tasks in.
[Osamu Aoki] This is basically way to present equivalent packages as an alternatives under the menu entry for virtual package.
Yes. Is the current virtual package system enough for such a
I mean: afaik it's designed to cover the need of application dependencies, not of user tasks.
For example, rcalc does not "Provides: calculator", since there is no package that has a dependancy on a calculator application. However, I can imagine that some user would like to choose among the different alternatives of calculator applications for one to install.
[Osamu Aoki] Not just 1 level but follow its tree.(removing this package would involve removing these others: do I still want to remove it?)
add your ideas to the list
Once we have some analysis and we documented a set of tasks the application is to be used for, we will have a strong, common ground from which we can proceed:
|[Debian Usability Research home page] - [deb-usability-list] - [Alioth project page]||Enrico Zini|