Mailinglist Archive: opensuse-packaging (89 mails)
| < Previous | Next > |
Re: [opensuse-packaging] [Proposal] Suggests/Enhances Support in RPM/YaST
- From: Gustavo Niemeyer <gustavo@xxxxxxxxxxxx>
- Date: Wed, 21 Dec 2005 00:20:34 -0200
- Message-id: <20051221022034.GB14598@xxxxxxxxxxxxxxxxxxxxx>
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
> 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
| < Previous | Next > |