Re: [opensuse-packaging] Ideas for advanced Enhances / Suggests
Stanislav Brabec wrote:
Hallo.
I have a package libgda, which contains many database plugins.
What to do with plugin packages, which provide a xxx support for libgda.
Suppose I will do:
Package: libgda-mysql Enhances: libgda
Package: libgda-postgres Enhances: libgda
This will probably cause, that beginner will click OK for all and package manager will install all available databases as hard-dependencies of all these plugins.
Lets resolve the issue here, where it originates from, instead of hardcoding assumptions about the user preferences into packages: Display the enhancing packages in a way that the user is not tempted to click ok for all.
But I want to suggest here: "Yes, libgda-mysql enhances libgda, but if you don't have mysql installed, you probably have no usage for it." Once in future, if user installs mysql package, libgda-mysql should be suggested.
What I really need, is probably: Enhances: ( libgda + mysql )
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?
One of suggestions says, do not offer or warn about enhancement packages with a lot of unresolved dependencies. But it is not a solution.
For example I have also:
Package: gstreamer-plugins-extra Enhances: gstreamer
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..
Is such feature possible or planned or what is the syntax?
And additional ideas:
Is it possible to use Enhances for virtuals or Suggests for symbols instead of package name? I want to say: "Yes gimp-help enhances both gimp and gimp-unstable."
Package: gimp-help Enhances: gimp-2.0
Package: gimp Provides: gimp-2.0
Package: gimp-unstable Provides: gimp-2.0
Both the hard/soft dependencies are after Provides (if I'm correct), there should be no problem.
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. Best Regards, Marian
Marian Jancar wrote:
What I really need, is probably: Enhances: ( libgda + mysql )
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.
One of suggestions says, do not offer or warn about enhancement packages with a lot of unresolved dependencies. But it is not a solution.
For example I have also:
Package: gstreamer-plugins-extra Enhances: gstreamer
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.
And additional ideas:
Is it possible to use Enhances for virtuals or Suggests for symbols instead of package name? I want to say: "Yes gimp-help enhances both gimp and gimp-unstable."
Both the hard/soft dependencies are after Provides (if I'm correct), there should be no problem.
Soft dependencies are evaluated by higher level tools. If these tools will be aware on symbols, not only package names, then yes.
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." -- Best Regards / S pozdravem, Stanislav Brabec software developer --------------------------------------------------------------------- SuSE CR, s. r. o. e-mail: sbrabec@suse.cz Drahobejlova 27 tel: +420 296 542 382 190 00 Praha 9 fax: +420 296 542 374 Czech Republic http://www.suse.cz/
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
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 etc. -- Best Regards / S pozdravem, Stanislav Brabec software developer --------------------------------------------------------------------- SuSE CR, s. r. o. e-mail: sbrabec@suse.cz Drahobejlova 27 tel: +420 296 542 382 190 00 Praha 9 fax: +420 296 542 374 Czech Republic http://www.suse.cz/
-----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 píše v St 04. 01. 2006 v 23:12 +0100:
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).
It seems you are right. One can want install libgda on minimal system, because (s)he wants to use databases, and (s)he can expect, that libgda will support it. I am going to add Enhances: libgda to libgda-xxx. Your suggestion seems to be good: You can enhance libgda by following packages: libgda-mysql no additional dependencies libgda-odbc list of additional dependencies: ... libgda-oracle dependency problem: ... Thinking about it, YaST already has a similar dialog for dependency conflict. It also asks user for solution. -- Best Regards / S pozdravem, Stanislav Brabec software developer --------------------------------------------------------------------- SuSE CR, s. r. o. e-mail: sbrabec@suse.cz Drahobejlova 27 tel: +420 296 542 382 190 00 Praha 9 fax: +420 296 542 374 Czech Republic http://www.suse.cz/
participants (3)
-
Marian Jancar -
Pascal Bleser -
Stanislav Brabec