First, I'm a user, not a maintainer. I'm in a debate with a package
maintainer that could be endless and so I'd like a your expertise to
help end it. The maintainer is
breaking his own dependant packages with every version change, and he
says that's the only way to do it. His reason for this is in the
README.Debian file below. From what I can gather, he uploads
claws-mail, and then waits for it come back to him via apt-get, then he
tries to build claws-mail-extra-plugins. My suggestion to him was to
install claws-mail via dpkg -i and then build claws-mail-extra-plugins
and then upload all the packages at once. This way, he'd know
everything would build before he uploaded.
His answer to this was:
"I'm sorry but I never upload packages built in dirty environments.
And even
doing what you suggest it only solves the issue for the architecture
being
uploaded (which, btw, is not the one you're using), for the rest the
extra-plugins would fail to build until claws-mail is built. Have a
look on
how the autobuilders work. Anyway, like I've already said in other bug
[0],
this is handled better in next version."
His reasoning doesn't seem valid to me, but I'm not a maintainer. I
don't want to debate with the guy. Could someone tell me if there is a
way he can upload all his claws-mail-* packages at once without
breaking his dependant packages for days (6 so far).
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=490304
Here's the README.Debian file mentioned in the bug report as
== /usr/share/doc/claws-mail-extra-plugins/README.Debian ==
claws-mail-extra-plugins for Debian
-----------------------------------
This is a collection of external plugins for Claws Mail.
Plugins are dynamic libraries and as such they must share a common ABI
with the host application to work properly. As the ABI is currently in
development, the plugin code must check the Claws Mail version at
load time so it matches the version the plugin was compiled with. Not
doing so will result in unpredictable behaviour because of the ABI
changes.
This represents no problem for internal plugins because they are
recompiled at the same time Claws Mail is, so version always matches.
OTOH, external plugins doesn't know when Claws Mail version has
changed, so packages for external plugins have to be rebuilt with each
new *upstream* version (Debian version changes shouldn't modify ABI).
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.
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.
To summarize, when loading a plugin if you see the popup message:
"Your Claws Mail version is newer than the
version the plugin was built with"
then you have to wait until a new plugin package enters the archive.
Alternatively you may put claws-mail package on hold until all external
plugins you use are uploaded and then upgrade both claws and the
plugins at the same time.
-- Ricardo Mones <mones@debian.org> Mon, 26 Jun 2006 07:24:14 +0200