Hi, On Mon, Sep 23, 2024 at 05:51:34AM -0000, Helmut Grohne wrote: > Source: syncmaildir > Severity: important > User: helm...@debian.org > Usertags: sidremove > > Dear maintainer, > > I suggest removing syncmaildir from Debian for the following reasons: > * It accumulated one RC-bug: > + #1000322: locking issues can lead to complete mail spool destruction > Last modified: 2 years > > * It is not part of bookworm or trixie and is not a key package. > > This bug serves as a pre-removal warning. After one month, the bug will be > reassigned to ftp.debian.org to actually request removal of the package. > > In case the package should be kept in unstable, please evaluate each of the > RC-bugs listed above. > * If the bug is meant to permanently prevent the package from entering > testing > or a stable release, but this package should stay part of unstable, please > add a usertag: > > user helm...@debian.org > usertags NNN + sidremove-ignore > > * If the bug no longer applies, please close it. If it is closed, check > whether the fixed version is correct and adjust if necessary. > > * Is the bug really release-critical? If not, please downgrade. > > * If the bug still applies, please send a status update at least once a year. > > Once all of the mentioned RC bugs have been acted upon in one way or another, > please close this bug. > > In case the package should be removed from unstable, you may reassign this > bug report: > > Control: severity -1 normal > Control: retitle -1 RM: syncmaildir -- RoM; rc-buggy > Control: reassign -1 ftp.debian.org > Control: affects -1 + src:syncmaildir > > Alternatively, you may wait a month and have it reassigned. > > In case you disagree with the above, please add a wontfix tag to this bug. > > Control: tags -1 + wontfix > > Doing so will also prevent automatic reassignment.
I would be tempted to mark it as such, but I'm somehow biased. I still have one setup which syncmaildir is used. Some observations: - The services which Antoine mentions are examples in the source code, the smd-loop script provided in the package itself should hopefully not run in that situation. - Locking is still bugy as found and potentially acked by the back then upstream, and data lost is defintively on RC severity - Upstream has archived the project, and there is no active development. - Apart the issue which lead to this bugreport, there is another RC level issue in fact, syncmaildir FTBFS with gcc-14. - The alternatives might be sensible enough to switch at. Disclaimer: I still might be wrong on the above items, just though to put some comments on this request for removal from unstable bug. so in the end maybe this report is perfectly valid and syncmaildir should be removed, but maybe there is as well a way to salvage the project. I'm not tempting it as there is enough on my plate :) Regards, Salvatore
