Re: about volatile.d.o/n
On Sat, Oct 09, 2004 at 03:44:13PM -0400, Kevin Mark wrote:
> 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
Apologies Stephen, you will need to correct me, but here goes:
email
|
V
stuff
|
libs -{api.3}------ {api.4}
| |
V V
sigs -{api.1}-> engine -{api.2}-> frontend
|
{api.4 or 5}
|
V
stuff...
> the api for {lib} and {frontend} must be in sync.
> update {lib} api and then you would have to update all {frontends}.
> does not sound like 'stable' policy?
if {api.2} changes then presumably frontend must change.
> the data format used in {data} and read by the {lib} must be in sync.
> update the {lib} may lead to a change in data format which would
> probably lead to an api change which would mean updates to all
> {frontends}. ugh!
I imagine it is quite possible for {api.1} to change without impacting
{api.2}. Indeed, I suppose that to be part of the value of {api.2}.
If it actually exists. I confess, I made it up.
> 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?
see my previous mail.
> clam-data has an updated but not all similar frontends do.
> what is done for others that do not have 'freshclam'?
This is in flux, and part of the problem being discussed. See for
instance discussion of snort rules and oinkmaster, or nessus-plugins.
> what is the diff between
> stable.update,security.update,volitile.update?
> enquiring minds what to know? hope this is not too OT!
Don't know, but I guess perhaps this is a question for Andi.
Regards,
Paddy
> -Kevin
>
>
> --
>
> (__)
> (oo)
> /------\/
> / | ||
> * /\---/\
> ~~ ~~
> ...."Have you mooed today?"...
no, why do you think I should ???
--
Perl 6 will give you the big knob. -- Larry Wall
Reply to: