On Debian and Fedora experiences

Jeff Spaleta jspaleta at gmail.com
Wed Dec 6 22:41:07 UTC 2006


On 12/6/06, Christoph Wickert <christoph.wickert at nurfuerspam.de> wrote:
> > And how do you expect automated tools to handle these soft requirements?
>
> Maybe with a popup: "Foo suggests bar. Do you want to install bar? Y/N"

Logic fault.... to be automated inherently means... no interaction
from the user.

At best you suggest means a pop-up with a timeout, for each and every
suggestion.
This does not scale out to something sane.

Personally I think the Suggests crap is nitpicky and borders on being
symptomatic obsessive compulsive disorder.  The amount of effort to
make it work is out of line with its potential benefits since it does
nothing to solve the underlying  problems associated with how upstream
projects are dealing with complex application featuresets.

Problem 1:
Buildtime library dependancies for "non-critical" functionality
(according to some users of the application), which the executables
are linked against at buildtime. Such libraries must be present on the
system at runtime or you will get error loading shared library errors.
 There is no way a set of tags in a binary package can deal with this
hard requirement and make it go away. I believe the entire
aalib/mplayer discussion in this thread is an example of this. You
have to rebuild the package to get rid of the requires and have a
functional application.  This is why the rpm build process detects and
adds linked library requirements at package buildtime, so as a
maintainer you don't have to make guesses about what is and what is
not linked in.

And I claim the majority of gripes which bring up
Suggests/Optional/Recommends as potential packaging solutions are
really buildtime issues that individual upstream projects need to
address and can't be solved at the packaging level.  If its meant to
be an optional runtime feature, then the upstream project needs to
have a buildprocess which characterizes that library as a runtime
detactable object.  If upstream projects continue to treat collections
of "optional" features as buildtime decisions, then the upstream
project developers are tieing the hands of binary distributors, and
taking flexibility away from end-users who are relying on binary
distributors.  If these sorts of issues are a problem for you, as a
linked library obsessed admin, gentoo is the distribution level
solution for you.

What what would be useful as a metric and as an aid for the future
incarnations of this discussion, and I know this isn't going to
happen, is a way to diagnose whether a binary package requires was
autoadded or explicitly added by the maintainer, just from rpm queries
of the installed packages.  Yes there are situations where maintainers
(ab)use explicit requires, but to have informed discussion about these
issues, we need to make it easier for the misinformed to better
distinguish buildtime generated deps from package maintainer action.

Problem 2:
Applications and frameworks that are designed to have runtime
detectable plugins, tend to develop a non-trivially large set of
plugins.  Any packaging mechanism which ties a large collection of
potential plugins together as suggestions, on an equal basis, will be
a duantingly complex iteractive experience for package management.

How many gstreamer plugins are there? How many of them could be
considered.. optional, by someone of discerning tastes?  I don't
really need theora video right?   If we had
Suggests/Recommnds/Optional tags and could break-up the gstreamer
plugin space to be as fine-grained as possible, would it really help?
Would we really make anyone happy by having a UI which would
interactively query the user if they want each and every gstreamer
plugin?  Msdness.  At best we could flag these things as Optional so
they could be removed by the local admin, after they were installed.
But to design a UI which let you crawl through this much detail at
install time.. is just perverse and only serves the 0.5% of the
userbase with a an unhealthy package management fetish.

-jef"What if we packaged firefox extentions as rpms, how exactly would
you you draft a fair Suggests policy for that plugin space...
absolute... madness. "spaleta




More information about the fedora-extras-list mailing list