Max Spevack wrote:
Would like to open up a few of these questions for some input from you
guys. This is not a replacement for a larger draft of the answers --
this is just as I work on some of the other questions, here's a few that
I can't answer alone.
-----------------------------
7) Dependency hell
(Score:5, Interesting)
by Tet
The introduction of yum has vastly improved the user experience when
installing software, or updating existing packages. However, it's
brought with it a new kind of dependency hell. For example, if I want to
install a PostScript previewer:
% yum install evince
[...]
Installing:
evince x86_64 0.5.1-3 core 773 k
Installing for dependencies:
nautilus x86_64 2.14.1-1.fc5.1 updates-released 3.9 M
nautilus-cd-burner x86_64 2.14.2-1 updates-released 414 k
That's clearly wrong. I only want to install a PostScript previewer.
Doing so should not require a filemanager (which I don't need or want),
and certainly not a CD burner. But these are added as dependencies due
to the clumsy packaging that seems to be increasingly prevalent in
Fedora. Perhaps (and I remain unconvinced) there's some aspect of evince
that can make use of nautilus being present. But if so, I haven't seen
it. I could well believe that nautilus could make use of evince, but not
really the other way around. But assume for the sake of argument that it
can use nautilus. That still isn't a reason to have it depend on it.
Dependencies should be packages that are required in order for another
to run, not packages that will merely enable additional functionality.
In this case -- the prime function of evince is to view documents, which
isn't significantly enhanced by having a file browser present.
In this specific example, we can probably split things up to have a
nautilus-evince sub package but since Evince is linked against the
nautilus extension interface this is not a totally stupid dependency. It
is also of important that Evince is a universal document viewer and not
just a postscript previewer and naturally requires more dependencies.
Fedora is still my distribution of choice, but it's becoming
increasingly hard to use for those of us that prefer to run with a
minimal system due to the way that the dependencies have been getting
out of hand. Are there any plans to fix this, or is any work already
underway to do so?
There are some ongoing efforts to split up package on occasions and by
demand. Filing bug reports when people spot unneeded dependencies or
ones that could be cleaned up would be helpful.
I understand that some consideration has been given
to providing "soft dependencies" within RPM (like dpkg's suggested
dependencies), which would help. Is there a timeframe for this? Is
anything else being done?
We havent updated the Fedora RPM to the latest upstream version which
provides the "soft dependencies" feature. Whether we would prefer to use
this particular feature is undecided yet. In many cases, simply
splitting up packages would work better without pushing the users to
choose since soft dependencies can make QA harder.
I quite understand the focus on getting the system to be usable for the
average unskilled user. But the impression I'm getting is that it's
being done at the expense of letting those of us that know what we're
doing do what we want. Does Fedora have a position on the type of users
it's aiming for, or is it still trying to be a general purpose OS?
Right on spot. The balance is sometimes between splitting up packages to
save some space and memory and having things work better by default.
Fedora having the Red Hat Linux lineage made Fedora Core tilted towards
the "unskilled" users and Fedora Extras to have more fine grained
dependencies. Now what the guidelines have been unified several packages
where the binaries where in the same package as the libraries have
been split up. ex: XMMS in Fedora Extras, PHP in Fedora Core...
Having more packages in the repositories allows makes it easy to justify
splitting up packages since some of them would require the libraries and
not the binaries and so on.
We are likely to move incrementally into having more fine grained
dependencies in every release.
Rahul
_______________________________________________
fedora-advisory-board mailing list
fedora-advisory-board@xxxxxxxxxx
http://www.redhat.com/mailman/listinfo/fedora-advisory-board
_______________________________________________
fedora-advisory-board-readonly mailing list
fedora-advisory-board-readonly@xxxxxxxxxx
http://www.redhat.com/mailman/listinfo/fedora-advisory-board-readonly
