This one time, at band camp, Kevin Mark said:
> On Sat, Oct 09, 2004 at 10:43:05AM -0400, Stephen Gran wrote:
> > This one time, at band camp, Kevin Mark said:
> > > On Sat, Oct 09, 2004 at 11:00:51AM +0200, Francesco Paolo Lovergine wrote:
> > > > On Sat, Oct 09, 2004 at 03:01:11AM -0400, Kevin Mark wrote:
> > > > > Packages like virus checkers seem to be
> > > > > composed of 2 parts: the app program and the data where the data in
> > > > > this case are virus sigs and the app is say clamav. And the 'volitile'
> > > > > part is the virus sigs whereas the app (once it hits stable) shouldnt
> > > > > change unless it warrents a 'security' update. So, volitile should be
> > > > > for the data/virus sigs that need updating when new bugs hit the 'net.
> > > >
> > > > No, often such kind of programs need engine update. That's true for
> > > > both AV and antispam programs as well.
> > > >
> > > Hi Francesco,
> > > so:
> > > the program = engine part + (some un-named part) ???
> > > and the engine part and the data part are volitile
> >
> > In the case of clamav, most of the work of scanning is handled by
> > library functions, and these functions are called by the frontend
> > programs like clamscan, clamdscan, and the milter.
> Hi Stephen,
>
> so,
> email
> |
> \/
> {lib}clamav->clamav{frontend}<-clamav-{data}
> |
> \/
> mbox
This might be a more helpful diagram:
email
|
MTA<--->clam frontend
| |
| library<-->data set (sigs)
mbox
Clam doesn't scan email in isolation - it's called by an MTA or a glue
application like amavis. The fact that the underlying library functions
or data sets have changed internally should not matter to the caller, so
long as the front ends have the same API. There is one application I
see outside of the clamav suite that links against libclamav1 directly,
and that will take careful coordination - all the others rely on the API
provided by frontends and will not break so long as the API remains
constant.
> would it be good to backport new dataformat to 'stable' dataformat or
> risk having to fix {lib} and {frontend}s? then they would be 'unstable'
> and need QA?
Not really - clam is dropping the ability to read unsigned datasets, and
while it would be technically possible to recreate signed signature sets
in an older format, the delay introduced by doing so would obviate the
advantage of having automatic updates. Also, clam currently relies on a
worldwide system of mirrors, each of which currently does about 10G of
traffic/month just for the clam updates. Where do you propose we host the
single mirror that will update all of the sarge installs that can't use
the newer data format? I don't have the bandwidth and I don't think
it's practical for p.d.o.
> what is the diff between
> stable.update,security.update,volitile.update?
> enquiring minds what to know? hope this is not too OT!
> -Kevin
My understanding is that stable-proposed-updates is for packages that
maintainers would like to see in the next point release, security is for
the security team and contains fixes for packages mentioned in DSA's,
and volatile is intended for packages that need to update more
frequently than point releases allow, but are not directly security
problems, and so are not the arena of the security team.
--
-----------------------------------------------------------------
| ,''`. Stephen Gran |
| : :' : sgran@debian.org |
| `. `' Debian user, admin, and developer |
| `- http://www.debian.org |
-----------------------------------------------------------------
Attachment:
pgppCzCEvRPno.pgp
Description: PGP signature