Re: courier will be missing in the next stable version of Debian and Devuan

Am 16.12.24 um 04:01 schrieb Sam Varshavchik:
> These kinds of things are always a question of supply/demand. If there's not
> enough Debuan user base to result in someone deciding to go ahead and put
> some elbow grease in this, then that's what it is.

Might be true abou Devuan, I do observe the demise of Debian package 
maintenance with worries, though. It's a self-fullfilling prophecy.

(TBH, though, I personally care much more about imap, auth and maildrop. 
Not so much about esmtpd.)


Can we break this down to better understand what the obstacles are?

Of course, someone could just build the debs using Sam's scripts and set 
up a deb-repository. Little work, but investing your time into a repo 
with no other purpose sounds a bit like a waste.

Or... someone finally takes over maintenance of the debian packages:

Maintainers:

- It seems there seem to be no other debian maintainers willing to adobt 
courier. Markus W. asked for help years ago.

- So, someone would have to become a new "sponsored" debian maintainer:
https://wiki.debian.org/SponsoredMaintainer

(If you think this is hard, read https://wiki.debian.org/DebianMaintainer )


Building the packages:

- A sponsored maintainer must produce debs. I noticed courier's build 
process is slightly... overcomplicated. (Why is that actually?) It 
produces debs though.

These debs should be adjusted for FHS and/or debian paths. And maybe 
have some defaults fixed. (Like IMAP_EMPTYTRASH. Oh my.) Best to put 
this into a patch. I believe most parts of courier are comparatively 
stable, so no real problems with patching. Also, nobody said you have to 
produce new packages for every minor version.

Upgrading:

- Upgrade scripts propably are no hard requirement. Just don't overwrite 
/etc/courier. After all, courier needs to be configured by the user 
anyway. ( something like /etc/courier/esmtpd.d/ could be helpful.)


Security:

- There's a little trouble about security patches. Security fixes must 
be backported to the version pinned in debian. New features are not 
permitted.

I don't think this is feasable without some support from Sam who would 
eventually have to split development into two branches - one with new 
features (if there ever are any), one without them.



There should be a way to get this done and establish a process that is 
little to no work...?

d.


_______________________________________________
courier-users mailing list
[email protected]
Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users