[aur-general] Move pigeonhole to [community]?
Hi fellow TUs, Are there any objections if I move pigeonhole (dovecot sieve plugin) from the AUR to [community]? It's got 9 votes at the moment, but there's a potential problem in that if pigeonhole isn't built against the installed version of dovecot, mail delivery breaks. So, the idea would be to keep dovecot in [community] and depend on the current version of dovecot *only*. This way people can't update their system in such a way as to break mail delivery. This make sense to you? Cheers, Pete.
On 20.11.2010 17:56, Peter Lewis wrote:
So, the idea would be to keep dovecot in [community]
dovecot is in extra. Otherwise go for it :) -- Florian Pritz -- {flo,bluewind}@server-speed.net
On Saturday 20 November 2010 17:22:34 Florian Pritz wrote:
On 20.11.2010 17:56, Peter Lewis wrote:
So, the idea would be to keep dovecot in [community]
dovecot is in extra.
Yeah, dovecot is in extra, maintained by Andreas. Personally, I'd be even happier for pigeonhole to go in there too and for the two to be built together each version bump, but I don't have that power :-)
Otherwise go for it :)
Thanks, I will... unless Andreas wants to take it on and start building it together with dovecot itself...?
On Sat, 20 Nov 2010 17:27:34 +0000 Peter Lewis <plewis@aur.archlinux.org> wrote:
On Saturday 20 November 2010 17:22:34 Florian Pritz wrote:
On 20.11.2010 17:56, Peter Lewis wrote:
So, the idea would be to keep dovecot in [community]
dovecot is in extra.
Yeah, dovecot is in extra, maintained by Andreas. Personally, I'd be even happier for pigeonhole to go in there too and for the two to be built together each version bump, but I don't have that power :-)
Otherwise go for it :)
Thanks, I will... unless Andreas wants to take it on and start building it together with dovecot itself...?
By now it has 10 votes(not mine) so go ahead, it's fine with the rules. -- Jabber: atsutane@freethoughts.de Blog: http://atsutane.freethoughts.de/ Key: 295AFBF4 FP: 39F8 80E5 0E49 A4D1 1341 E8F9 39E4 F17F 295A FBF4
On Sat, 2010-11-20 at 17:27 +0000, Peter Lewis wrote:
On Saturday 20 November 2010 17:22:34 Florian Pritz wrote:
On 20.11.2010 17:56, Peter Lewis wrote:
So, the idea would be to keep dovecot in [community]
dovecot is in extra.
Yeah, dovecot is in extra, maintained by Andreas. Personally, I'd be even happier for pigeonhole to go in there too and for the two to be built together each version bump, but I don't have that power :-)
Just a user comment, it can get a bit frustrating when direct dependencies like these are in community/extra (different maintainers). vlc-pulse-plugin for example (though that's not a good example, its normally updated within 12 hours). Maintaining together is a win, from my perspective =)
On Saturday 20 November 2010 23:37:55 Ng Oon-Ee wrote:
On Sat, 2010-11-20 at 17:27 +0000, Peter Lewis wrote:
On Saturday 20 November 2010 17:22:34 Florian Pritz wrote:
On 20.11.2010 17:56, Peter Lewis wrote:
So, the idea would be to keep dovecot in [community]
dovecot is in extra.
Yeah, dovecot is in extra, maintained by Andreas. Personally, I'd be even happier for pigeonhole to go in there too and for the two to be built together each version bump, but I don't have that power :-)
Just a user comment, it can get a bit frustrating when direct dependencies like these are in community/extra (different maintainers). vlc-pulse-plugin for example (though that's not a good example, its normally updated within 12 hours).
Maintaining together is a win, from my perspective =)
I agree, and if Andy wants to take on pigeonhole in extra, then that's fine with me :-) I think having pigeonhole in community like this is at least better than having it in the AUR, since people were losing mails if they didn't notice a dovecot upgrade and hence didn't recompile pigeonhole. Pete.
On 21/11/10 10:16, Peter Lewis wrote:
On Saturday 20 November 2010 23:37:55 Ng Oon-Ee wrote:
On Sat, 2010-11-20 at 17:27 +0000, Peter Lewis wrote:
On Saturday 20 November 2010 17:22:34 Florian Pritz wrote:
On 20.11.2010 17:56, Peter Lewis wrote:
So, the idea would be to keep dovecot in [community]
dovecot is in extra.
Yeah, dovecot is in extra, maintained by Andreas. Personally, I'd be even happier for pigeonhole to go in there too and for the two to be built together each version bump, but I don't have that power :-)
Just a user comment, it can get a bit frustrating when direct dependencies like these are in community/extra (different maintainers). vlc-pulse-plugin for example (though that's not a good example, its normally updated within 12 hours).
Maintaining together is a win, from my perspective =)
I agree, and if Andy wants to take on pigeonhole in extra, then that's fine with me :-)
I think having pigeonhole in community like this is at least better than having it in the AUR, since people were losing mails if they didn't notice a dovecot upgrade and hence didn't recompile pigeonhole.
Shouldn't pigeonhole just have a very specific versioned dependency on dovecot (at least depends=('dovecot=$_dcpkgver'), if not adding a $_dcpkgrel there too). That would stop dovecot being upgraded without pigeonhole also being upgraded. Allan
On Sunday 21 November 2010 00:34:39 Allan McRae wrote:
Shouldn't pigeonhole just have a very specific versioned dependency on dovecot (at least depends=('dovecot=$_dcpkgver'), if not adding a $_dcpkgrel there too). That would stop dovecot being upgraded without pigeonhole also being upgraded.
Yep, that's what I've done; it's in [community] now. I believe that just the pkgver should suffice, since when it breaks, it checks the version number of the running dovecot and if different from the linked-against one, bails out. It's probably worth also mentioning that if a new version of dovecot ever ends up in [testing] (or some other unstable repo), there should probably be an accompanying build of pigeonhole... is this what [community-testing] is for? Cheers, Pete.
On 21/11/10 21:24, Peter Lewis wrote:
On Sunday 21 November 2010 00:34:39 Allan McRae wrote:
Shouldn't pigeonhole just have a very specific versioned dependency on dovecot (at least depends=('dovecot=$_dcpkgver'), if not adding a $_dcpkgrel there too). That would stop dovecot being upgraded without pigeonhole also being upgraded.
Yep, that's what I've done; it's in [community] now. I believe that just the pkgver should suffice, since when it breaks, it checks the version number of the running dovecot and if different from the linked-against one, bails out.
It's probably worth also mentioning that if a new version of dovecot ever ends up in [testing] (or some other unstable repo), there should probably be an accompanying build of pigeonhole... is this what [community-testing] is for?
Yes. [testing] and [community-testing] are a pair.
participants (5)
-
Allan McRae
-
Florian Pritz
-
Ng Oon-Ee
-
Peter Lewis
-
Thorsten Töpper