On Sun, 10 Jan 2010 16:40:19 +0000 Tony Houghton <h...@realh.co.uk> wrote:
> Package: claws-mail-html2-viewer > Version: 3.7.3-1 > Severity: normal > > > I know we already went over this in #535753 but the thread accidentally > went to private email, and I've now noticed something I didn't before. > > As often happens, a version of claws-mail (3.7.4-1) has become available > in unstable some time ahead of a compatible version of > claws-mail-extra-plugins (still 3.7.3-1) and I've had to manually revert > to the "testing" versions because the dependencies failed to prevent > claws-mail 3.7.4-1 from being installed by apt-get upgrade when older > versions of claws-mail-html2-viewer etc were installed and had no > candidates for upgrade. > > In #535753 I thought you considered this to be acceptable and had some > strange reason for deliberately not fixing it, but I've just checked > /usr/share/doc/claws-mail-extra-plugins/README.Debian and part of it > claims the implemented solution is (like) the one I want, not the one > that actually exists: > > : On current packaging there is no way to express the dependency on > upstream : version only, so the implemented solution is to relax the > dependency to : greater or equal than the current upstream version and > introducing a conflict : with the next upstream version, so the plugin can > effectively live with any : of the possible Debian revisions without > needing to be rebuilt. > > The crucial bit is "a conflict with the next upstream version"; there > isn't one and I want one, please. However, this does seem to contradict > the following two paragraphs. The next paragraph says: > > : This solution has at least one problem: it depends on a future value of > the : version string. If upstream versioning scheme changes the version > range : expressed by the current Depends/Conflicts pair may be wider than > expected : and include the newer upstream version. In practice that means > the old plugin : package won't be uninstalled when the new Claws Mail > version gets : installed. This has already happened with releases 0.9.12a > and 0.9.12b. > > This could be resolved by instead of trying to predict the next upstream > release number, use the current upstream release with a very high debian > release number that will never be used, for example, instead of > claws-mail-extra-plugins-0.9.12-* having: > > Conflicts: claws-mail (>= 0.9.13-1) > > use: > > Conflicts: claws-mail (>> 0.9.12-99) > > Or perhaps Conflicts is too strong, because it might force manual > uninstallation of one package before the other can be upgraded? So > couldn't you instead use (I'm not sure if there's a special syntax for > depending on a package being between two versions): > > Depends: claws-mail (>= 0.9.12-1), claws-mail (<= 0.9.12-99) > > That should allow apt-get to upgrade both packages together when both > are available, while apt-get upgrade would keep claws-mail back until > a compatible claws-mail-extra-plugins became available, keeping me > happy. I understand what you want, but the problem is that there's no reason they should be upgrading together. They're independent packages and people not using extra-plugins may claim I'm artificially preventing claws-mail to be upgraded just because extra-plugins are not there (like every time a new plugin is added and it has to go through new queue, this time for the new geolocation plugin). If I understood it correctly that would also prevent it to migrate testing new versions if, for example, one plugin has a RC bug. And that's not good, because while resolves your problem brings other problems in for all users. As dependencies are now set it's allowed both upgrading claws-mail alone disregarding the extra-plugins status, and also people, like you, using extra-plugins, decide when to upgrade, as it's very simple to detect that claws-mail is being upgraded but not the extra-plugins. If you see the extra-plugins are not coming in you already know they're not going to work (I'm talking about new upstream versions, of course). I know is not perfect, but your solution it isn't either, and IMO this one is the less bad of both. Maybe this explanation is not implicit on the README.Debian, I'll be glad to improve it if you want. regards, -- Ricardo Mones http://people.debian.org/~mones «Living your life is a task so difficult, it has never been attempted before.» -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
