Stanislav Brabec wrote:

...

Such assumption as what the user probably has or has not usage for doesn't belong to low level stuff like a package. A package cannot (and should not) know everything about all the system and the about the user preferences. In this case, what if the user intends to use a mysql on a remote machine?

If mysql client libraries are not installed, (s)he probably don't want.

The plain presence of a package is not an indication. For good results a more advanced heuristic is required, and this is simply not task of a package. The libgda-mysql is nice example how attempts to fine-tune this on an inapropriate level will break. As Reinhard said, the libraries will be present, becouse they are required by zillion another packages.

...

...

The package also has many unresolved dependencies, but I really want to suggest here: "Yes, install all these dependencies to have a cool gstreamer package." Whether a package is cool for a user depends on his preferences, something a high level setup tool can know about but a package cannot..

But packager should know, that it is perfectly possible to use libgda without libgda-mysql (only not for MySQL databases), but it is hard to use gstreamer without gstreamer-plugins-extra (because it is not able to play many common audio format). But it is still not hard-dependency, because your music player is still able to play WAV without it.

Perfect reason for a Suggests.

...

...

Maybe it should be evident, why package Suggests/Enhances other package, to provide enough information to user. For example:

Package: mc Suggests: (xv eog gv pdftotext)("To provide default viewers. You can define different viewers and ignore these suggestions.")

Package: gnome-session Suggests: gnome2-user-docs("To provide enhanced user documentation.") The purpose should be obvious from the suggested package description.

In other cases it is not obvious, that: "Without package yyy, you will be able to use all tools from xxx except zzz, which is not commonly used."

This, as oposite to attempting to hide the Suggestion, is a valid reason for complex Suggests expressions, to describe that aaa is enhanced by xxx and even more by xxx and yyy but not enhanced by yyy alone. Best Regards, Marian

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Stanislav Brabec wrote:

Marian Jancar wrote:

...

...

If mysql client libraries are not installed, (s)he probably don't want. The plain presence of a package is not an indication. For good results a more advanced heuristic is required, and this is simply not task of a package.

The libgda-mysql is nice example how attempts to fine-tune this on an inapropriate level will break. As Reinhard said, the libraries will be present, becouse they are required by zillion another packages.

Well, think about libgda-oracle, libgda-msql or libgda-odbc. There is not many packages requiring oracle client library.

My suggestion is simple: libgda, but no oracle client library => do not suggest oracle plugin libgda, but no msql client library => do not suggest msql plugin

I don't quite agree. It really depends on the context, on what the user is doing. As Marian wrote, this is extremely complex to know (i.e. near unfeasible in my opinion with this approach). What would help is what aptitude is doing on Debian: differenciate between an explicit installation of a package (like: "yes, I want mysql") and implicit installations to resolve dependencies (install libgda-mysql, which will install mysql-shared as a dependency). Aptitude has the following ability: when you later remove the package libgda-mysql, it prompts the user to ask whether it should also remove mysql-shared (as long as it isn't needed by other dependencies). It's similar to a reference counting algorithm: when the last package that has mysql-shared as a dependency is removed and mysql-shared was installed implicitely (i.e. to resolve a dependency), then also remove mysql-shared (or, at least, prompt the user to do so). Such information would _help_ being smart enough as to try to understand what the user wants but: - - it is still very complex to handle, even with that information - - tools that try to be too smart usually miss the target and become annoying, make problems - - even more, I'm afraid that adding such heuristics to, say, YaST2's Package Management, would cause it to be annoying at best, a piece of crap at worst, because it does "weird things" (i.e. things the user did not intend to do but YaST2 thought he wanted to) And, to come back to the idea of the "context" of the user action... Usually the user would go the other way around: - - install libgda, then install the plugins needed (= the databases he wants to work with) - - install libgda-mysql ==> will install mysql-shared through plain Requires: - - install libgda-oracle ==> will.. well... won't, it's not included on 10.0 but you get the picture ;) cheers - -- -o) Pascal Bleser http://linux01.gwdg.de/~pbleser/ /\\ <pascal.bleser@skynet.be> <guru@unixtech.be> _\_v The more things change, the more they stay insane. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDvEg/r3NMWliFcXcRAu3PAJ9/gq7FkO+zzfFuF1W2j9xmvqPPRwCgoaB7 Ip3dWovlStkitlHHbgFhoGc= =WxJw -----END PGP SIGNATURE-----