[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: yum



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


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]