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 -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
