Feature Proposal: Use cases database

[Nicolas Mailhot]

Le Jeu 11 septembre 2008 12:40, Richard Hughes a écrit :
>
> 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?

Digital-photo forum wants to define an initial setup for new members
(automating read the FAQ install x, y and maybe z)

So it defines a set composed of

root set:
mandatory: photo managing set
default: photo editing set
optionnal: fancy hardware support set and photo publication set

photo editing set:
default: most popular bitmap editor (gimp...)
optionnal: less popular editors some people prefer (krita...)
optionnal: specialized plug-ins (raw support, etc)

photo managing set
default: most popular picture manager
optionnal: less popular managers, plugins, docs, localization

fancy hardware support set
optionnal: hardware support for fancy printers, colorimeter support,
cameras not exposed as usb mass storage, etc

photo publication set
default: xyz
optionnal: gallery2 set

gallery2 set
mandatory: gallery2 core packages
default: most popular plugins
optionnal: less popular plugins

And that's a very focused example. An entity like Fedora's art team
will want to provide a setup for people working on vector icons, on
sound sets, on bitmap backgrouds (or several of those at once).

Replace digital-photo forum with foo community and you'll get pretty
much the same results

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

This is so trivial it presents almost no interest at all. If you want
to go mono-app please consider eclipse, openoffice or firefox and
their gazillon of plugins and extensions.

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

Then your format is too complex. It *does* need validation (all the =
; () ). If you want an imperative-only simplified list of resources to
install kickstart did it better with less fuss.

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

Well that's not the syntax on your own web page (misses ;) so we've
answered the question of your format being simple enough to be typed
by memory without validation

>> 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:
> C
>
> 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 a ridiculous example.
Any "Cool stuff in GNOME" post will say
APP A is a cool way to do 1
APP B is a cool way to do 2
APP C is a cool way to do 3

And post readers are perfectly able to decide if they want to do 1, 2,
3 on their computer and the vast majority of users won't want to do
the full set of things that interests the initial poster.

(and the http://www.packagekit.org/pk-profiles.html page is very clear
that your users *do* know what they want to do with their computer)

What they do want is to click on a link, get the list of A, B and C,
and uncheck the apps targetting stuff they're not interested in.

And BTW a resource list format that targets this kind of use case
needs to allow associating comments to every resource, so instead of a
stupid

A B C list

The user gets a

A "Cool way to do 1"
B "Cool way to do 2"
C "Cool way to do 3"

list (with optional localisation of course)

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

Wrong, anyone not sitting on a fiber to his home.
Which is the normal state of non-developper people who have other
priorities than the size of their network pipesa.

Think your openoffice user is going to appreciate downloading megs of
optionnal openoffice stuff just in case?

Think your latex man is interested in installing megs of fonts for
languages he does not type? (how do you decide beforehand which
language a latex user will want to type)

Will the music junkie be interested in dvd playback and authoring
tools (just because the average teenager does both music and video)?

Presets are fine. Inflexible presets lead to resource waste and menu
clutter users do complain of.

-- 
Nicolas Mailhot