[Proposal] Suggests/Enhances Support in RPM/YaST
hi, beside the minor problems we had with th rpm 4.4.2 update, we got a new cool feature: Enhances/Support Flags for a rpm. Some people might know them from Debian. Sadly RPM doesnt honor those flags yet. But SmartPM and the new YaST Package manager will support them. Semantics behind the 2 rpm tags --------------------------------- Basically both work similar to Provides/Requires. Atm the information will be just passed into the base package. RPM wont tell you about the relation ship. That work has to be done by high level tools. 1. Suggests ============= "Suggests" is a weak "Requires". You can suggest big packages, you dont want to enforce. A prominent example might be the hard requirement in taskjuggler to kdepim. Especially Gnome users dont like that much. 2. Enhances ============= "Enhances" can be used to promote addon packages. An amarok addon could declare itself as an enhancement of the amarok base package. That way we dont have to know all possible addon packages in the base package, but still be able to present the information to the user. Klaus Kaempf mentioned as another possible use case enhances on hardware detected in the box. Atm we install the synaptic driver in the default selection without checking if the box has a synaptics touch pad. xorg-xinput-synaptics could specify "Enhances: hwinfo(x11:synaptic-touchpad)" and SaX2 will only ask to install this rpm if the hardware is really found. Possible Solution inside YaST ------------------------------- Below the package listing you have this small info box where you can read the package description/technical informations/Requires|Provides list. An additional tab could be added to this area and the list of additional packages could be shown there. Or the usual dependency solving dialog could be presented. comments/critics welcome. Marcus p.s.: the original bug for this proposal https://bugzilla.novell.com/show_bug.cgi?id=136757
Hey Marcus!
beside the minor problems we had with th rpm 4.4.2 update, we got a new cool feature:
Congratulations for the upgrade. Jeff Johnson is probably drinking a beer today to celebrate it. :-)
Enhances/Support Flags for a rpm.
You probably mean Enhances/Suggests here. There's also Recommends, besides these. Detailed documentation is available at: http://www.debian.org/doc/debian-policy/ch-relationships.html
Some people might know them from Debian. Sadly RPM doesnt honor those flags yet. But SmartPM and the new YaST Package manager will support them.
Right!
Semantics behind the 2 rpm tags ---------------------------------
Basically both work similar to Provides/Requires. Atm the information will be just passed into the base package. RPM wont tell you about the relation ship. That work has to be done by high level tools.
1. Suggests =============
"Suggests" is a weak "Requires".
You can suggest big packages, you dont want to enforce. A prominent example might be the hard requirement in taskjuggler to kdepim. Especially Gnome users dont like that much.
Both Recommends and Suggests are weak requirements. The difference is that Recommends is a highly advised dependency, while Suggests defines a soft suggestion.
2. Enhances =============
"Enhances" can be used to promote addon packages. [...]
Yes, Enhances is Suggests reversed.
Possible Solution inside YaST -------------------------------
Below the package listing you have this small info box where you can read the package description/technical informations/Requires|Provides list. An additional tab could be added to this area and the list of additional packages could be shown there. Or the usual dependency solving dialog could be presented.
That's the tricky part. While I completely agree that showing them up is a good start, we should try to implement a sensible way of using that information. We cannot just install them, because otherwise it becomes a true requires. Asking the user to confirm is a bit tricky, since we may get into "suggests of suggests" and become boring. So we should try to understand what is a good way of handling them. That's the part where we create a flame war and then try to collect some useful ideas afterwards. ;-) -- Gustavo Niemeyer http://niemeyer.net
Gustavo Niemeyer <gustavo@niemeyer.net> writes:
[...] We cannot just install them, because otherwise it becomes a true requires. Asking the user to confirm is a bit tricky, since we may get into "suggests of suggests" and become boring. So we should try to understand what is a good way of handling them.
We could install them - this gives the chance to install a package if it is available on the media and not fail if not... But perhaps this is not the intended behaviour ;-)
That's the part where we create a flame war and then try to collect some useful ideas afterwards. ;-)
Let's collect ideas directly ;-) Andreas -- Andreas Jaeger, aj@suse.de, http://www.suse.de/~aj SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126
On Wed, Dec 21, 2005 at 09:31:00AM +0100, Andreas Jaeger wrote:
Gustavo Niemeyer <gustavo@niemeyer.net> writes:
[...] We cannot just install them, because otherwise it becomes a true requires. Asking the user to confirm is a bit tricky, since we may get into "suggests of suggests" and become boring. So we should try to understand what is a good way of handling them.
We could install them - this gives the chance to install a package if it is available on the media and not fail if not... But perhaps this is not the intended behaviour ;-)
My idea about this is that there should be a switch in YaST "Automatically install packages that are suggested by other packages". This allows the users that just want to have a useful system to get all these packages without looking up hundreds of thousands of things and it allows the users that want to save every byte that is not really required on their disk to turn all suggests globally off. I recommend to have this switch turned on by default because most users are most likely served best if they have too much software installed than when something is missing. Another switch might be useful that selects whether YaST should display a dependency resolver question when the issue is only caused by honouring the suggests feature. Robert -- Robert Schiele Tel.: +49-621-181-2214 Dipl.-Wirtsch.informatiker mailto:rschiele@uni-mannheim.de
My idea about this is that there should be a switch in YaST "Automatically install packages that are suggested by other packages". This allows the users that just want to have a useful system to get all these packages without looking up hundreds of thousands of things and it allows the users that want to save every byte that is not really required on their disk to turn all suggests globally off. I
Interesting option indeed. I'm not sure if I'd like to have that as the only possible way to handle the option, but looks like a good start. Perhaps we could base on that to create some kind of user interface to enable/disable additional suggested/recommended packages on-the-fly.
recommend to have this switch turned on by default because most users are most likely served best if they have too much software installed than when something is missing.
I'm not completely sure about this though. Depending on the network of packages, installing a package could bring the whole repository with it, and package management is not so useful anymore. There's also the issue of space and bandwidth constraints. Depending on your vendor's repository size, it may become impossible to install everything, and even if you do install everything, it might mean getting many uninteresting upgrades constantly.
Another switch might be useful that selects whether YaST should display a dependency resolver question when the issue is only caused by honouring the suggests feature.
Yep.. that's part of the "expected behavior" issue. Notice that installing a suggested package is not an atomic operation. You must satisfy the dependencies of the suggested package as well, and the suggested package and its requirements may have other suggestions. Doing those operations without user knowledge is not an option, in my opinion. It could bring a hundred packages to install a single package with a single suggestion. -- Gustavo Niemeyer http://niemeyer.net
Hi Andreas!
[...] We cannot just install them, because otherwise it becomes a true requires. Asking the user to confirm is a bit tricky, since we may get into "suggests of suggests" and become boring. So we should try to understand what is a good way of handling them.
We could install them - this gives the chance to install a package if it is available on the media and not fail if not... But perhaps this is not the intended behaviour ;-)
At least having an option to treat Recommends and/or Suggests as Requires would be nice indeed. I'm not sure about the not-found-in-media behavior though. This would mean we'd have to scan files to tell the user what would be installed and what wouldn't. It'd also mean different settings for local and remote repositories, or would become quite expensive if we had to check for remote availability of packages.
That's the part where we create a flame war and then try to collect some useful ideas afterwards. ;-)
Let's collect ideas directly ;-)
Humm.. interesting.. never thought about that approach. :-) -- Gustavo Niemeyer http://niemeyer.net
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Andreas Jaeger wrote:
Gustavo Niemeyer <gustavo@niemeyer.net> writes:
[...] We cannot just install them, because otherwise it becomes a true requires. Asking the user to confirm is a bit tricky, since we may get into "suggests of suggests" and become boring. So we should try to understand what is a good way of handling them.
We could install them - this gives the chance to install a package if it is available on the media and not fail if not... But perhaps this is not the intended behaviour ;-)
I don't think that's the idea. Thing is, some people prefer having a minimalistic approach and only install what they really need, and other people prefer having all features available. Maybe the user could configure his "profile" in YaST2 ? 3 options: 1) only install minimal feature set (= don't install Suggests:) 2) install complete feature set (= automatically install Suggests:) 3) ask me every time (1) would never install the packages in Suggests, without asking (unless directly needed through Requires in another package, obviously) (2) would always install the packages in Suggests, without asking (3) would always prompt the user to choose whether he also wants to install the packages in Suggests (including the package name and the description, for each package in Suggests), e.g. using a list of checkboxes 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) iD8DBQFDqYN4r3NMWliFcXcRAn9WAJ9DwCa/1ucxLUNobNWpDvUxqHqRNQCghXQz TFuTN0Sj+q6v9hvAQkZwPSY= =elTC -----END PGP SIGNATURE-----
Am Mittwoch, 21. Dezember 2005 09:31 schrieb Andreas Jaeger:
Gustavo Niemeyer <gustavo@niemeyer.net> writes:
[...] We cannot just install them, because otherwise it becomes a true requires. Asking the user to confirm is a bit tricky, since we may get into "suggests of suggests" and become boring. So we should try to understand what is a good way of handling them.
We could install them - this gives the chance to install a package if it is available on the media and not fail if not... But perhaps this is not the intended behaviour ;-)
That's the part where we create a flame war and then try to collect some useful ideas afterwards. ;-)
Let's collect ideas directly ;-)
Suggested packages should not be installed automatically. But they should be presented to the user, so he can select himself, which packages he really needs and which not not. Currently, after selecting packages with new requirements in yast, a dialog is shown (german: "Automatische Änderungen"), where yast presents all packages pulled in by these require-tags. The checkboxes in front of the packagenames are set and cannot be changed. This dialog is a good place to show suggested packages too, in an unselected but selectable state. If the user selects one of these unselected packages, the packelist must be updated, to reflect new requires and suggested packages. Cheers Herbert
On Wed, Dec 21, 2005 at 12:20:34AM -0200, Gustavo Niemeyer wrote:
beside the minor problems we had with th rpm 4.4.2 update, we got a new cool feature:
Congratulations for the upgrade. Jeff Johnson is probably drinking a beer today to celebrate it. :-)
Don't remind me of the pain I had with the update. Rpm source is a fragile beast, the configure options don't work well, there are couple of changes in the semantics and the API, in short: no fun at all. I hope I don't have to do an update for the next two years. Cheers, Michael. -- Michael Schroeder mls@suse.de main(_){while(_=~getchar())putchar(~_-1/(~(_|32)/13*2-11)*13);}
On Wed, 21 Dec 2005, Michael Schroeder wrote:
beside the minor problems we had with th rpm 4.4.2 update, we got a new cool feature:
Don't remind me of the pain I had with the update. Rpm source is a fragile beast, the configure options don't work well, there are couple of changes in the semantics and the API, in short: no fun at all.
If I read this correctly it's not an option to upgrade rpm on SUSE 10 to the rpm version in factory? What are the big changes?
I hope I don't have to do an update for the next two years.
If SUSE will keep rpm current the changes might not be so big.
Cheers, Michael.
Best regards, Aschwin Marsman -- aschwin@marsman.org http://www.marsman.org
Aschwin Marsman <aschwin@marsman.org> writes:
On Wed, 21 Dec 2005, Michael Schroeder wrote:
beside the minor problems we had with th rpm 4.4.2 update, we got a new cool feature:
Don't remind me of the pain I had with the update. Rpm source is a fragile beast, the configure options don't work well, there are couple of changes in the semantics and the API, in short: no fun at all.
If I read this correctly it's not an option to upgrade rpm on SUSE 10 to the rpm version in factory?
NO, you shouldn't - since you need to update other packages as well. rpm is linked against glibc 2.4 CVS, Andreas -- Andreas Jaeger, aj@suse.de, http://www.suse.de/~aj SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126
On Wed, 21 Dec 2005, Andreas Jaeger wrote:
Aschwin Marsman <aschwin@marsman.org> writes:
On Wed, 21 Dec 2005, Michael Schroeder wrote:
beside the minor problems we had with th rpm 4.4.2 update, we got a new cool feature:
Don't remind me of the pain I had with the update. Rpm source is a fragile beast, the configure options don't work well, there are couple of changes in the semantics and the API, in short: no fun at all.
If I read this correctly it's not an option to upgrade rpm on SUSE 10 to the rpm version in factory?
NO, you shouldn't - since you need to update other packages as well. rpm is linked against glibc 2.4 CVS,
Well, you could take the sources out of Factory and build an rpm package for 10.0 -- but it might break your rpmdb. What are you expecting from an updated rpm package for 10.0? Regards Christoph
On Wed, Dec 21, 2005 at 01:29:13PM +0100, Christoph Thiel wrote:
Well, you could take the sources out of Factory and build an rpm package for 10.0 -- but it might break your rpmdb. What are you expecting from an updated rpm package for 10.0?
No, it uses the same database. The new rpm isn't tested very well, so I don't advise you to do the upgrade. Cheers, Michael. -- Michael Schroeder mls@suse.de main(_){while(_=~getchar())putchar(~_-1/(~(_|32)/13*2-11)*13);}
On Wed, Dec 21, 2005 at 01:18:33PM +0100, Aschwin Marsman wrote:
If SUSE will keep rpm current the changes might not be so big.
Heh, you obviously don't know much about rpm developement... Cheers, Michael. -- Michael Schroeder mls@suse.de main(_){while(_=~getchar())putchar(~_-1/(~(_|32)/13*2-11)*13);}
participants (10)
-
Andreas Jaeger -
Aschwin Marsman -
Christoph Thiel -
Dirk Mueller -
Gustavo Niemeyer -
Herbert Graeber -
Marcus Rueckert -
Michael Schroeder -
Pascal Bleser -
Robert Schiele