Denis Leroy wrote: > I feel the most important thing must remain ease of installation for > end-users. If you "yum install foo", you expect foo to be fully working > after installation (and how many dependencies it pulls is not > necessarily important if you're using yum directly). Remember we don't > really have a mechanism in place to say "since you just installed foo, > you should really consider installing foo-extras, foo-extensions and > foo-plugins as well. Creation of dummy metadata packages (i.e. payload-less packages that simply have requires and provides metadata) works as is... the package maintainer for foo could simply create a 'foo-complete' package that has all the others required. But at the same time, the user who wants only foo and foo-extensions could get them if they choose. > And then there's installing from pirut. If I want to install clamav, I > open up pirut and search for "clamav". I get 17 packages. Which one do I > have to install to have a sufficient setup ? Splitting packages to make > dependencies easier to manager is a good idea, but first we may want to > think about ways to make this less confusing to the end user. When I > search for clamav, I'd like to see a big red line for the main clamav > installation line (with all the dependencies it will pull hidden from > view), and a side panel with a list of optional packages (plugins and > al) with descriptions. Do we have enough metadata right now to produce > something like this ? The metadata is certainly there, with the packages that require the one you're trying to install, or require something it provides (i.e. clamav). The issue is development of those frontend UIs that handle these things sanely... and with more features, options, views, and sub-lists. To make it happen right now would probably require more dependency handling/processing time though, making the applications even slower. -- Andrew Farris <lordmorgul@xxxxxxxxx> <ajfarris@xxxxxxxxx> gpg 0xC99B1DF3 at pgp.mit.edu No one now has, and no one will ever again get, the big picture. - Daniel Geer ---- ---- -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
