On 12/6/06, Christoph Wickert <christoph.wickert@xxxxxxxxxxxxxx> 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 -- fedora-extras-list mailing list fedora-extras-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-extras-list
