Add versioned package dependency for maximum XUL application version

[Anders Kaseorg]

The current xul-ext-lightning package has
Recommends: icedove (>= 7.0~a2) | iceape (>= 2.1) | thunderbird (>= 7.0~a2) | seamonkey (>= 2.1)
which does not give any indication that it will stop working with Thunderbird 8, even though it will.

Please add something like
Breaks: icedove (<< 7.0~a2), icedove (>= 7.+), iceape (<< 2.1), iceape (>= 2.2.+), thunderbird (<< 7.0~a2), thunderbird (>= 7.+), seamonkey (<< 2.1), seamonkey (>= 2.2.+)

which corresponds to the minimum and maximum versions given in install.rdf (thunderbird 7.0a2 - 7.*, seamonkey 2.1 - 2.2.*).

[Micah Gersten (micahg)]

I assume mozilla-devscripts is generating this, so it should be generating the range as well.

[Benjamin Drung (bdrung)]

What algorithm should be used for generating ${xpi:Breaks}? Should we really have break items for too old xul applications?

Examples:

1) install.rdf specifies 9.0a1 as max version for firefox. The corresponding Debian version is 9.0~a1 (use moz-version for the conversion). How should the breaks field look like?

2) install.rdf specifies 1.0.* as max version for prism. How should the breaks field look like?

[Anders Kaseorg (andersk)]

> What algorithm should be used for generating ${xpi:Breaks}?

For maxVersion, I suggest
  • append 0 to a trailing letter, or
  • append + to a trailing number, or
  • replace a trailing * with +.

maxVersion 9.0a ⇒ break (>= 9.0~a0)
maxVersion 9.0a1 ⇒ break (>= 9.0~a1+)
maxVersion 9.0 ⇒ break (>= 9.0+)
maxVersion 9.0.* ⇒ break (>= 9.0.+)

No changes are needed for minVersion beyond what moz-version already does.

> Should we really have break items for too old xul applications?

I think this is necessary to stop the extension from being upgraded if the upgrade would increase minVersion beyond the application’s installed version. Admittedly, that’s a less common problem than the other direction.

[Benjamin Drung (bdrung)]

Ok, time to implement it.

[Benjamin Drung (bdrung)]

I committed the fix as described in comment #3. Please test this stuff.

[1] http://anonscm.debian.org/gitweb/?p=pkg-mozext/mozilla-devscripts.git;a=commitdiff;h=cc52fe459c05b2588f635d5bf90ff9eaddb1f0f1

[Anders Kaseorg (andersk)]

It seems that an earlier commit b3edbbb broke mozilla-devscripts by moving /usr/share/pyshared/moz_version.py to /usr/share/pyshared/src/moz_version.py:

   dh_xul-ext
Traceback (most recent call last):
  File "/usr/bin/dh_xul-ext", line 24, in <module>
    from moz_version import (compare_versions, convert_moz_to_debian_version,
ImportError: No module named moz_version

[Benjamin Drung (bdrung)]

Fixed in [2].

[2] http://anonscm.debian.org/gitweb/?p=pkg-mozext/mozilla-devscripts.git;a=commitdiff;h=55869ffc370604e71307910774169aaad154c0d4

[Anders Kaseorg (andersk)]

I recompiled xul-ext-lightning after adding ‘Breaks: ${xpi:Breaks}’ to all its debian/control stanzas, and ended up with what appears to be the right thing. The result installs and works.

Package: xul-ext-lightning
Provides: imap-client, mail-reader, seamonkey-lightning, thunderbird-lightning
Depends: xul-ext-calendar-timezones, libc6 (>= 2.7), libnspr4 (>= 4.7.3-0ubuntu1~), libstdc++6 (>= 4.1.1)
Recommends: thunderbird (>= 7.0~a1) | seamonkey (>= 2.4~a1), xul-ext-gdata-provider
Suggests: latex-xft-fonts
Breaks: seamonkey (>= 2.4.+), seamonkey (<< 2.4~a1), thunderbird (>= 7.+), thunderbird (<< 7.0~a1)
Enhances: seamonkey, thunderbird

[Launchpad Janitor (janitor)]

This bug was fixed in the package mozilla-devscripts - 0.29

---------------
mozilla-devscripts (0.29) unstable; urgency=low

  [ Benjamin Drung ]
  * Move mozilla-devscripts under the hood of the Debian Mozilla
    Extension Maintainers.
  * Remove Fabien Tassin and Alexander Sack from Uploaders. Thanks
    for your work.
  * Removed all stuff that is unrelated to packaging XUL extensions.
  * Switch from dpkg-source 1.0 to 3.0 (native).
  * Updated VCS location.
  * Relicense my stuff under the ISC license.
  * Add ${xpi:Breaks} for versioned package dependency for maximum
    XUL application version (LP: #839130).

  [ Andrea Veri ]
  * debian/control:
    - long and short desc refreshed a bit with new content.
    - added myself into uploaders, I'll help Benjamin maintaining this package.
  * debian/copyright:
    - refreshed and made it compliant to DEP-5.

 -- Benjamin Drung <email address hidden> Wed, 12 Oct 2011 00:10:04 +0200

[Launchpad Janitor (janitor)]

This bug was fixed in the package lightning-extension - 1.0+build1-0ubuntu2

---------------
lightning-extension (1.0+build1-0ubuntu2) precise; urgency=low

  * debian/control: Add ${xpi:Breaks} to enforce maximum XUL application
    versions. (LP: #839130)
 -- Anders Kaseorg <email address hidden> Tue, 08 Nov 2011 16:31:02 -0500

[Chris Coulson (chrisccoulson)]

I strongly disapprove of this in lightning, and as the maintainer, I probably should have been consulted before this was uploaded.

The issue you're trying to solve is only a "problem" for people running the beta version of Thunderbird (which is everybody in precise or people opting in to the thunderbird-next PPA. The latter group already accept some risk that there will be periods where addons may not work). Rather than adding workarounds like this which will block Thunderbird upgrades in the future for people who opt in to the thunderbird-next PPA (thus, reducing our already minimal test coverage), it would be much more productive for people to instead help by uploading a version of lightning which works.

Note, this change also prevents upgrades to the Earlybird version of Thunderbird (in the thunderbird-aurora PPA), for which we don't provide any compatible versions of lightning at all.

[Chris Coulson (chrisccoulson)]

In addition to that, people who choose to accept that they can work without Lightning for a few days and want to upgrade Thunderbird, are forced to uninstall Lightning, meaning that they miss out on the next update anyway.

[Anders Kaseorg (andersk)]

Should we remove every versioned dependency from the Ubuntu archive, then, just because people running beta versions accept some risk that there will be periods where some packages might not work? Say precise is in the middle of a Perl transition—should all the packages depending on old Perl just remain on my system in a completely nonfunctional state while Perl is upgraded anyway, just because the maintainer thinks that I chose to accept that I can work without those packages for a few days, but it’s too inconvenient to temporarily uninstall them?

If not, what makes _this_ versioned dependency so special?

It seems to me that a user either (a) wants Lightning, in which case they’ll have the package installed, and they’ll want incompatible upgrades blocked, or (b) doesn’t want Lightning, in which case they’ll just uninstall the package, on the off chance that it was installed to begin with. I have trouble imagining your hypothetical user that (c) wants Lightning but is happy to have it taken away from them for a few days by surprise on any system upgrade. If you want the (a) users to be willing testers of Thunderbird betas and Ubuntu betas, the answer is to upload compatible versions of Lightning, not to try to force them towards (c).

[Micah Gersten (micahg)]

There isn't always a compatible version available. So now instead of having the addon disabled in thunderbird and upgraded to a working version when it's available, they'll now have it uninstalled and have to go hunt for it again, only to find that it's uninstallable and not sure why.

[Anders Kaseorg (andersk)]

Micah, I understand that there isn’t always a compatible Lightning available. But like I said, I’m having trouble imagining a user that wants to upgrade Thunderbird anyway, only to discover _after_ the upgrade that there’s no compatible Lightning.

I also understand that, _if_ a user who wanted Lightning had gotten into a bad situation where there’s no Lightning compatible with their Thunderbird version, then they might want a working version installed automatically when it becomes available. But they’ll be happier if we avoid putting them in that bad situation to begin with.

My questions above remain unanswered (what makes _this_ versioned dependency special, and why do users want (c) instead of (a) or (b)?).

(By the way, I assumed the appropriate maintainers would be automatically informed when I submitted the merge proposal; please let me know if I should have done something different.)

[Micah Gersten (micahg)]

This one is different due to the update frequency. Most apps aren't updated every 6 weeks in a stable release (or almost weekly in the dev release). Most apps don't have channels which users might want jump between for different versions. In theory, what you proposed was correct, but in practice, it'll seemingly cause more problems than it's worth. At least if it's not compatible, the user can easily seen in addons that it's not compatible and start to wonder when a compatible version will come (these should be updated simultaneously in the stable releases). With the Breaks, the user will see that a Thunderbird update is available, but not be told why it can't be installed. This seems more frustrating. Also, Firefox and Thunderbird are things that people want almost immediately. Addon lag is, unfortunately, a natural part of the rapid release cycle, so it's not even unexpected by most users. It's not liked by any means, but not unexpected.