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 <[EMAIL PROTECTED]> Mon, 26 Jun 2006 07:24:14 +0200 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
