On Saturday 19 May 2007, Manoj Srivastava wrote: > Well, for non-buggy packages, what you have is an issue of > trusting the maintainers judgement. In that case, you also have to > trust that the maintainer comes up with a correct, and properly > formulated explanation in under one line; which correctly emphasizes > the importance of the dependency relationship. > Unless you are a $Deity, or have conducted an extensive > analysis, this is a matter of judgement. By putting things as > recommends, the maintainer is saying, yes, it is a good thing to > install these packages together. > If you think the maintainers judgement is off, and have some > proof, file a bug to reduce the depndency. > > > Anyway, it was just an example out of many. For non-core packages, > > Recommends often add functionality that I'll never use but the package > > maintainer uses them daily. Why should I install it then? > > You don't have to. But you are saying you do not trust the > maintainers judgement, so asking in 80 characters or so why things are > needed is not likely to help. I have to strongly disagree with the opinion that this shows distrust in the maintainers judgement for 2 reasons IMO: 1) wanting more information is (in itself) in no way a sign of distrust 2) maintainers make decisions that are supposed to be reasonable to a regular user. However not everyone is a regular user, and in situations where one isn't, you might want to reexamine the decisions made. Not because of trust issues, but simply because some of the underlying assumptions might not apply Informing people is a Good Thing. So what if only a small percentage of our users will ever use the extra information, I don't see how the existence of that information would cause any problems -> so as long as somebody is willing to do the work for providing it I don't see the problem with supporting a standard system for putting the information in the user's hands. -- Cheers, cobaco (aka Bart Cornelis)
Attachment:
pgp3U0Ez9r7RF.pgp
Description: PGP signature