Is it conceivable that sa-update might be separated from the main spam
assassin repo in the future, and be part of a sa-rules package?
It might require the comparison of the SA Update version in place, and
the spamassassin main packages installed?
That way changes to the way updates are handled/retrieved would not need
to rely on a complete SA release..
On 18-09-04 11:23 AM, Kevin A. McGrail wrote:
Yeah, that's my thought though there is a sub for that.
I think this change makes sense:
Index: sa-update.raw
===================================================================
--- sa-update.raw (revision 1840051)
+++ sa-update.raw (working copy)
@@ -26,7 +26,7 @@
# Subversion keyword "$Id$" has been successfully expanded.
# Doesn't happen with automated launchpad builds:
# https://bugs.launchpad.net/launchpad/+bug/780916
- $VERSION = 'svn' . (split(/\s+/, '$Id$'))[2];
+ $VERSION = &Mail::SpamAssassin::Version . ' / svn' . (split(/\s+/,
'$Id$'))[2];
}
my $PREFIX = '@@PREFIX@@'; # substituted at 'make'
time
On 9/4/2018 1:27 PM, Michael Peddemors wrote:
On 18-09-04 10:21 AM, [email protected] wrote:
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7006
--- Comment #2 from Kevin A. McGrail <[email protected]> ---
It is updated during the build process but why are we using an svn
version at
all for sa-update?
3.4.1:
sa-update version svn1652181
running on Perl version 5.16.3
3.4.2 pre 5:
sa-update version svn1838992
running on Perl version 5.16.3
Do we want this to be a blocker for 3.4.2, kick to 3.4.3 or mark
resolved,
won't fix and that it's working as intended?
On the updated sa-update working on release for.. went with..
sub print_version {
print "sa-update version $VERSION\n"
. " Installed SpamAssassin version $SAVersion\n"
. " Running on Perl version " . join(".", map { $_||=0; $_*1 }
($] =~ /(\d)\.(\d{3})(\d{3})?/ )) . "\n";
}
$SAVersion is gathered via..
my $SAVersion = get_installed_SA_version();
my $RevSAVersion = join(".", reverse split(/\./, $SAVersion));
sub get_installed_SA_version {
# Figure out what version of SpamAssassin we're using, and also
figure out the
# reverse of it for the DNS query. Handle x.yyyzzz as well as x.yz.
my $SAVersionStr = $Mail::SpamAssassin::VERSION;
if ($SAVersionStr =~ /^(\d+)\.(\d{3})(\d{3})$/) {
$SAVersionStr = join(".", $1+0, $2+0, $3+0);
} elsif ($SAVersionStr =~ /^(\d)\.(\d)(\d)$/) {
$SAVersionStr = "$1.$2.$3";
} else {
die "fatal: SpamAssassin version number '$SAVersionStr' is in
an unknown format!\n";
}
return $SAVersionStr;
};
I know.. a little 'hokey' but trying to conform to legacy methods..
Was just readying an email on the subject of versions..
SA-Update should be independent of the installed SA, but does need to
check what version for some actions..
Per offline and online discussions, this will help facilitate rules
being separate from actual SA code base in the future, but trying to
take baby steps..
--
"Catch the Magic of Linux..."
------------------------------------------------------------------------
Michael Peddemors, President/CEO LinuxMagic Inc.
Visit us at http://www.linuxmagic.com @linuxmagic
A Wizard IT Company - For More Info http://www.wizard.ca
"LinuxMagic" a Registered TradeMark of Wizard Tower TechnoServices Ltd.
------------------------------------------------------------------------
604-682-0300 Beautiful British Columbia, Canada
This email and any electronic data contained are confidential and intended
solely for the use of the individual or entity to which they are addressed.
Please note that any views or opinions presented in this email are solely
those of the author and are not intended to represent those of the company.
