Debian Package Manager brainstorming session

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

The transcript

Intended users

• Newbie Linux users, not in charge of administering the system
• Newbie Debian users, not in charge of administering the system
• Experienced non-technical Debian users, not in charge of administering the system
• Experienced technical Debian users, not in charge of administering the system
• Debian developers, not in charge of administering the system
• Newbie Linux users, in charge of administering the system
• Newbie Debian users, in charge of administering the system
• Experienced non-technical Debian users, in charge of administering the system
• Experienced technical Debian users, in charge of administering the system
• Debian developers, in charge of administering the system

[Osamu Aoki] I think these "User" thing can be summarized in 3 coordinates:

1. User::Skill::Developer/Experienced/Intermediate/Newbie
2. User::Taste::Technical/non-technical
   (Taste: There can be 2 types for "Technical" and this can be split. "detail" oriented control freak for *production* server admin and "easy" *personal* workstation admin.)
3. User::Access::wheel/staff/user
   (Access: wheel & staff may be merged as an administrator,)

Also "User" may have different focuses:

• User::Focus::Workstation::eduactional/medical/generic
• User::Focus::Server::generic/web/mail/firewall

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.

Purpose of the package management application

The main purposes of the package management application are: [Osamu Aoki]

1. to reduce task by the System administrator of any skill level and orientation, and
2. to provide information to the administrator and normal user for the availability and usefulness of the packages.

These two main purposes can in turn be decomposed in other subtasks:

• Navigation among the available packages
  • See what is available (what is in this Debian thing?)
  • See what kind of problems or tasks have some package in Debian that address them (what can I do with all these packages?)

    [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.

    [Enrico Zini] 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.

  • Examine the different alternative implementations for a given feature (what choice of word processors do I have?)

    [Osamu Aoki] This is basically way to present equivalent packages as an alternatives under the menu entry for virtual package.

    [Enrico Zini] Yes. Is the current virtual package system enough for such a feature?
    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.

• Search the package database
  • Find a specific package
    • By package name (I want to see gnumeric package informations)
    • By incomplete package data (what was that package I used last year, it sounded like abi-something?)
    • [John Hasler] By incomplete description or keywords (what package will solve the problem at hand?)
      90% of the time when I am rooting around among the available packages it is because I have a specific problem at hand and some notion of a package that, if it exists, will help me solve it.
• Manage the set of installed packages
  • See what is currently installed in the system (what has my system become?) (disk is nearly full: do I have something I could remove?)
  • Add/remove a single package (I wish to have libgnome2-dev for my project)
  • Add/remove a feature (I need a web server)
  • Manage dependencies (this package depends on these others: do I still want to install it?)

    [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?)
    (this package wishes to have a web server: which of the different alternative ones should I choose?)
    (this package suggests this other one: do I want it?)
    
  • System-wide actions
    • Upgrade the system
    • Upgrade to the next stable distribution
    • Remove cruft packages
    • [Osamu Aoki] Show the impact of any of the above actions prior to do them.
• Other random ideas might be:
  • show which packages are currently uninstallable
  • show which of the installed packages have open important/grave/critical or security bugs, or open bugs reported by me
  • show which of the installed packages have been orphaned
  • [Osamu Aoki] show which is maintained by DD or sponsored one
  • [Osamu Aoki] show low popcon rating of the packages installed
  • [Osamu Aoki] show high popcon rating of missing packages (Or we may need to reimpliment "better" popcon=popularity-contest.)

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:

• evaluate how is the current situation: where it is good and where it needs improvement
• elaborate proposed solutions and evaluate them
• build a roadmap for implementation, scattered with some user testing
• code, re-evaluating the current situation from time to time