Hi, On Thursday 17 July 2008 16:17:09 Thibaut Paumard wrote: [..] > > Then I believe the maintainer could do something with the > dependencies, but I'm not sure what. Setting Conflicts in claws-mail > on the previous version of the plug-ins would ensure that you don't > keep installed plug-in that don't work, so that you can decide to not > upgrade until those packages are upgradable. (This is true in > unstable as well).
Did I write yet that conflicts are not to be used to annotate that one package
breaks another?
>
> Actually, I thought that there would be a way of preventing claws-
> mail from migrating to testing until all the plug-ins can migrate as
> well, but I'm afraid that would mean _depending_ on all the plug-ins.
> Not sure whether _recommending_ would work for that purpose.
erm, with a package and plugins, it's the other way round:
The package itself must never depend on a plugin alone (otherwise there's no
reason why it should be a plugin in the first place). However a plugin is not
usable at all w.o. the application itself*, so the plugin must depend on it.
Hence the solution seems to be:
some-claws-mail-plugin
Depends: claws-mail (>= up.stream.version), claws-mail (<< up.stream.version+)
Now I'm not sure how britney works too much, but I guess that it would keep
the new claws-mail from migrating before the plugins are available as well,
because the old plugins would otherwise be unmet.
At least on a users system, this will have the effect, that claws-mail will be
held back, until new plugins are available.
*: corner cases like plugins working with two different applications aside.
HTH,
Stefan.
signature.asc
Description: This is a digitally signed message part.
