On 12/7/06, Christoph Wickert <christoph.wickert@xxxxxxxxxxxxxx> wrote:
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.
Your bugzilla example is a totally red-herring and the underlying problem is not solved by Suggests at all. The problem there is multiple applications can be used to fulfill the baseline functionality requirement. The underlying problem is how to best offer a default choice among equals. Suggests or Recommends doesn't solve that at all. A Suggests or Recommends does not in fact do anything other than state the maintainers preference to the user and encourage the user to install the maintainers stated preference regardless of whether or not its actually needed on the system. How is this really all that better than what version comparisons do now from a user standpoint? You put in a virtual provides into the multiple applications that provide the same functionality, then you put in an explicit requires on that virtual provide. The depsolver programatically decides which application to pull to fill that requires from among the equals that provide the same virtual provides IF the user doesn't already have an application installed already that can do the job. if the user does have an application that provides the functionality, no additional application is installed. Whereas with Suggests/Recommends there would be no way for the package management system to know if a user already has one of the applications installed that can be used to fill that function. Virtual provides solve the problem of choice among equals... suggests/recommends do not. I see no reason to implement a Suggests/Recommends in this situation, from an end-user perspective.
From a maintainer control situation, it has benefit. But quite
frankly, I don't really care all that much about giving maintainers more control over user systems.
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 you want to point out a very specific detailed example that makes sense, please by all mean do so. My concern is making sure the people who are talking about implementing it here, do so with appropriate examples that make sense. The aalib example, which dominated much of the early motiviation in discussing Suggests/Recommends in this thread... is completely and utterly without merit... as a point of discussion. I don't want to pick on Matej Cepl, but standing up aalib as a reason to move to Suggests/Recommends only confuses the issue, just as your bugzilla ticket does. And this tends to happen over and over and over again when this dicussion comes up in fedora every 6 months. The wrong examples are used as a point of discussion. I have yet to see an example in this thread which is an appropriate starting point to talk about Suggests/Recommends that solves a real current packaging problem in the fedora space. I know these situations exist, I can even idenfify examples, but I have no compelling reason to do so. I continue to be actively hostile to Suggests/Recommends so I'm not going to go out of my way to make it easier for people to argue for it. But I'm more than willing to continue a rational discussion about it, when the people who want it as a technical solution standup a current rpm packaging situation which is best served with Suggests/Recommends.
I guess I wouldn't be maintaining a single package here if gentoo was right for me. ;)
I make no claim that you act rationally, nor do I expect you to make rational self-consistent decisions. All I can do is point out rational self-consistent points of view with an aim towards directing the available development resources to make the most benefit for the future directions of this large scale project. I continue to think that the amount of resources needed to implement Suggests/Recommends is not worth the effort and I will continue to encourage developers to spend their time working on what I view as more important technical problems. I am also not above blackmailing developers with promises of mail-order Krispy Kreme doughnuts.
IHMO yes. gstreamer-plugins would become a meta-package, that would require/suggest the other plugins. Why not?
Yippie! Not just Suggests but meta-packages too. The mature handling of meta-packages requires even more packaging infrastructure and waste of development resources. Standing up more complexity to solve technical defects in an already too-complex Suggests idea, is a bad sign.
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.
With an installed user base of at least 100,000 people, 0.5% isn't are particularly small absolute number. Regardless, I see absolutely no evidence that Suggests/Recommends is an appropriate technical solution to the issue of default install size. To me Suggests/Recommends is an implementation idea in search of a problem to solve in the Fedora packaging policy space. Just because Debian does it, doesn't mean its a good idea to start using here. I garuntee we can make real headway on the install size of the default install scenarios without reaching for the complexity of building tools which understand how to process Suggests/Recommends.
Christoph "jef is is exaggerating once again" Wickert
-jef"You misunderstand me. I'm not saying the sky is falling. I'm saying the ground is exploding upward into the sky."spaleta -- fedora-extras-list mailing list fedora-extras-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-extras-list
