Feature Proposal: Use cases database

[Richard Hughes]

On Thu, 2008-09-11 at 11:27 +0200, Nicolas Mailhot wrote:
> I think this is a gratuituous distinction, and a full-blown distro
> comps file and a 3-line catalog file are just both ends of the same
> installation spectrum (with lots of people that could use something
> in-between).

Could you give me some use cases for a catalog please?

> Comps has the format necessary for its features and is in fact it is
> much simpler than the pk catalog format for what it does. I was quite
> horrified to see how complex the pk catalog format was for what it
> does.

Want to install gnome-do?

[PackageKit Catalog]
InstallPackages=gnome-do

> So you didn't consider the existing format, because XML is "bad", and
> you didn't think a lot about your format

Please don't tell me what I did and didn't think, I assure you I did do
lots of research before I started the feature.

> And lastly *because* users don't enjoy writing any config file (be it
> XML or not) they *need* a validation tools that tell them where they
> made typos (instead of hunting manually for missing parenthesis and
> such stuff).

Validation tools suck. If you need a validation tool, the format is too
complex, sorry.

> This means as soon as a project tries to support more and a handful of
> distributions it devolves in unmaintainable spaguetti mess. You've
> made it easy to write distro-specific exceptions instead of making it
> easy to write the common bits.

95% of the package names for _applications_ are common between all
distros.
99.9% (thanks Debian...) can be covered like this:

[PackageKit Catalog]
InstallPackages=gnome-packagekit packagekit-gnome

> Also, because you're mixing distributions but not considering
> scalability, that means a user that wants to check Fedora's cool
> configs site is going to need loading lots of different catalogs that
> all define stuff about distros he does not care about, instead of
> loading a single (or a limited number) of files that only target his
> distribution but at least are feature-complete.

No true, sorry. The example shown on the website is a worst-case
example, not the common case.

> In case you've not noticed it every installer be it anaconda or
> trivial windows aunt-tillie-oriented setup files expose component
> trees with some optional leaves, because optionnal nice to have but
> nor strictly necessary bits of an install set are a fact of life

Right, you're assuming the user knows if they want the optional package.
Have a look at these people: http://www.packagekit.org/pk-profiles.html

Do you think if any of those people know if they want gnome-do when they
install "Cool stuff in GNOME.catalog" from a forum post they saw?

> . This is one reason we do not do monster monolithic rpm packages because the
> #1 request of our users is always to have the possibility not to
> install everything in all cases.

Right, power users. Power user are not going to be installing packages
using silly little catalog files, they'll jump to the command line and
use the yum CLI directly.  PackageKit just isn't designed for these
types of user.

> Honestly, it does not feel you've spent enough time thinking on the
> subject.

That's your opinion. I've actually spent quite a lot of time doing user
research. The people on the profiles page are people I know well, and I
have either recorded screen-captures of what they did when asked to do
common tasks, or who I've asked then to explain to me what they would do
with a GUI over the phone.

Please don't think I'm going into this blindly, because I'm really not.

Richard.