On Debian and Fedora experiences

[Christoph Wickert]

Am Mittwoch, den 06.12.2006, 13:41 -0900 schrieb Jeff Spaleta: 
> 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.

I can't see no logic fault, because I also wrote some lines about fully
automatic installs, but you choose _not_ to quote them. ;) 

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

Maybe it is. But on the other hand I gave you two examples, where this
is not the case, where there are no additional BR:s and no runtime lib
requirements.

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

>From my debian experience Suggests: or Recommends: are not on shared
libs but on programs, so there's no need to rebuild anything.

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

And I claim the opposite: Suggests/Recommends _are_not_ on shared libs
and _are_ detected at runtime. I don't recall a single deb I had to
rebuild.

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

I guess I wouldn't be maintaining a single package here if gentoo was
right for me. ;) 

> 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?

IHMO yes. gstreamer-plugins would become a meta-package, that would
require/suggest the other plugins. Why not?

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

I don't think it's a fetish and I do think it's more then 0.5%. I know 
many people who don't use fedora because our packages and the default 
install tend to be too large.

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

Christoph "jef is is exaggerating once again" Wickert