>If a package, as installed, lacks a particular feature, >I'm more likely to assume the feature doesn't exist than to look for >optional extras. Looking for optional extras for each package - I have >1227 installed on my desktop system - that lacks some feature I would >like doesn't scale well. Might this, in part, be a metadata issue? Yum does well to resolve dependencies between packages (or reports they cannot be resolved), but the notion of "extras" - additional resources that are separately packaged, optional parts of another application - is not developed. (Or maybe it is... this would not be the first time SV has improved my understanding of yum.) Can a package have "weak dependencies" (such as -devel packages) that yum can be configured or told to install automatically? A couple of years ago, I was so frustrated by multiple, failed attempts to build applications because some <your_name_here>-devel package had not been installed that I wrote a program to iterate over every installed package name and report any matching, uninstalled "-devel" package available in a repository. After I told yum to install all those, build failures became interesting problems again. If we had a way to add "extra" (especially uninstalled) packages to a list of installed or available packages (because the metadata for listed packages identified these extras), would this make it significantly easier to find new or relocated function? There may be no reasonable way to add "extras" information formally to a package without a scary bump to the foundations of rpm. I really do not want to risk instability there, without a clearly visible need. An alternative would leave rpm contents alone and address this independently, as a documentation issue. Perhaps some external database could track "extras" and other aspects of application development. This is less elegant, because information about one thing is separated into two parts and two different actions may be required, but potentially more valuable. One can imagine a query that returns detailed history of a component (or a smaller piece... say an individual file) through multiple Fedora releases. Sure, this information is available somewhere. Or, rather, many somewheres. It would be nice if it were obvious and easy to learn about these things, especially for less experienced users. (It would also be nice if my computer understood all my questions, and could optimally answer them.) I hope this thread will incite suggestions about how to better manage modular packaging. We understand the real benefits we get when we build a system from hundreds of separately-managed parts. We still have to learn how to make it all come out right for a larger fraction of users. One place useful information might be added, without risk of instability, is in package descriptions. For example, F12 moved GNOME preferences for windows from the control-center package into a control-center-extra package. If some pointer had been put into the description for control-center, users might have an easier time to learn this - especially if this sort of track were provided often so one easily learned to look for it. (The F12 Release Notes lists control-center-extra, but says nothing about why it exists.) If we find some clever, standard format to add such details to descriptions, we might preserve the terse description of a package and offer multiple levels of detail in cases where more information is desired. No separate facility needed. I have mixed novice and expert issues in this comment. I belong in the expert camp - more interested in the gory details and think it's fun to figure out what made such a mess - but I believe the novice perspective is more important. Without modular packaging, Fedora would not exist (at least, not with a semiannual release schedule). Can the novice be more insulated from packaging issues, even if this entails some loss of efficiency? Let the experts build optimal systems; they can be expected to know when something is not right, and learn how to fix it. For the novice, "It should just work." -- fedora-test-list mailing list fedora-test-list@xxxxxxxxxx To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-test-list
