Attached is the spamassassin.spec currently in Fedora rawhide. There
are some ugly hacks in here that we may be able to remove if upstream
changes are possible.
* http://bugzilla.spamassassin.org/show_bug.cgi?id=3450
Prevent spamassassin service from starting by default for Fedora.
* Attached krb5-backcompat.patch is conditionally patched depending on
the location of the krb5.h. Would it be possible for the Makefile.PL to
detect the different locations of krb5.h automatically, so we don't need
this ugly hack?
Also the following I could use some comment.
* Any suggestions to improve the package "Summary" and "%description"
sections?
* Is the "get rid of auto white list" regex replacement too ugly a hack?
To be honest I was surprised when today's svn snapshot suddenly failed
when starting the service. This behavior will bite many server
administrators... many of whom would rather not read documentation and
would expect things to just work. Would it not be better to print a BIG
AND UGLY WARNING and not fail service startup? Perhaps also add the
warning to every spam mail too, saying something like, "Tell your System
Administrator that the auto-white list option is obsolete and must be
removed."
* Any other questions or comments about Fedora's spamassassin packaging?
NOTE:
I know that some people really want the Fedora package to be more in
sync with the upstream RPM packaging. I am very wary of doing so
because of the different package split, config locations and other
possible upgrade issues. Other RPM packages contain a ton of ugly
triggers and special case hacks to deal with broken states left by
poorly packaged or upgrade path mistakes from the past. I absolutely do
not want even the risk of a poorly thought out migration from one
packaging scheme to another, that may necessitate a further migration later.
I would be open to making changes like this during the FC3 development
cycle only after a very thorough analysis of upgrade paths from Red Hat
and Fedora's past spamassassin releases to the new packaging scheme is
done. This is not something I am interested in looking at now though.
I am tired of users demanding things like this without offering to put
work into making it happen.
Warren Togami
wtogami@redhat.com
are some ugly hacks in here that we may be able to remove if upstream
changes are possible.
* http://bugzilla.spamassassin.org/show_bug.cgi?id=3450
Prevent spamassassin service from starting by default for Fedora.
* Attached krb5-backcompat.patch is conditionally patched depending on
the location of the krb5.h. Would it be possible for the Makefile.PL to
detect the different locations of krb5.h automatically, so we don't need
this ugly hack?
Also the following I could use some comment.
* Any suggestions to improve the package "Summary" and "%description"
sections?
* Is the "get rid of auto white list" regex replacement too ugly a hack?
To be honest I was surprised when today's svn snapshot suddenly failed
when starting the service. This behavior will bite many server
administrators... many of whom would rather not read documentation and
would expect things to just work. Would it not be better to print a BIG
AND UGLY WARNING and not fail service startup? Perhaps also add the
warning to every spam mail too, saying something like, "Tell your System
Administrator that the auto-white list option is obsolete and must be
removed."
* Any other questions or comments about Fedora's spamassassin packaging?
NOTE:
I know that some people really want the Fedora package to be more in
sync with the upstream RPM packaging. I am very wary of doing so
because of the different package split, config locations and other
possible upgrade issues. Other RPM packages contain a ton of ugly
triggers and special case hacks to deal with broken states left by
poorly packaged or upgrade path mistakes from the past. I absolutely do
not want even the risk of a poorly thought out migration from one
packaging scheme to another, that may necessitate a further migration later.
I would be open to making changes like this during the FC3 development
cycle only after a very thorough analysis of upgrade paths from Red Hat
and Fedora's past spamassassin releases to the new packaging scheme is
done. This is not something I am interested in looking at now though.
I am tired of users demanding things like this without offering to put
work into making it happen.
Warren Togami
wtogami@redhat.com
Attached Files:
-
spamassassin-2.63-krb5-backcompat.patch (0.66 KB)
-
spamassassin.spec (5.41 KB)