Am Mittwoch, den 06.12.2006, 13:41 -0900 schrieb Jeff Spaleta: > 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. 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 -- fedora-extras-list mailing list fedora-extras-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-extras-list
