ejs at shubes
Jun 15, 2012, 6:51 PM
Post #14 of 19
On 06/15/2012 07:39 AM, Matt Olney wrote:
> On Fri, Jun 15, 2012 at 9:46 AM, Brian Morrison<bdm [at] fenrir> wrote:
>> On Fri, 15 Jun 2012 09:13:30 -0400
>> Matt Olney<molney [at] sourcefire> wrote:
>>> We're having some trouble with our freshmeat account. You can
>>> download the latest here, until we get it fixed up:
>> The download is 14MB odd, previous version have been 48MB and when I
>> run my rpm build script it tells me that the main and daily cvd files
>> are missing.
>> Brian Morrison
>> Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net
> It looks like our new build system doesn't bundle the .cvds. More
> accurately it ships 0-length main and daily cvds. For now you can, of
> course, run freshclam to pickup the signature files. We'll revisit the
> desired behavior (with or without cvds) and adjust our build process
> accordingly. Since you brought it up, do you have a preference or use-case
> that supports one behavior or the other?
I too am not the OP, but would like to chime in. I maintain the
qmail-toaster family of packages, of which clamav-toaster is one.
I think Brian hit the nail on the head, that it's "only a problem from a
packaging point of view". I also like that he splits the database out
into a separate package. This makes a lot of sense, and I'm going to
look into changing the way that the clamav-toaster package (rpm) handles
this. Thanks for the idea, Brian.
Redistributing the database (2/3 of the size of the download) makes no
sense when doing an upgrade, which is by far the majority of the cases.
Doing so is a total waste of bandwidth. At the same time, new installs
need to have these files one way or another, and can be obtained
efficiently either as a separate clamav-db package as Brian does, or
perhaps by running freshclam as a post-install process. In any case, I
think this is a decision best left to the packager.
The crux of the matter in my mind is that when the upstream packaging
changes, it tends to break things downstream. I honestly don't care if
the database comes in a separate tarball or not, as I'll write a spec
file accordingly. The bottom line to me is that things such as this
shouldn't change w/out letting people downstream know about it. Of
course accidents do happen, but the size of the file alone would seem to
be an indicator that something's not quite right. I also understand that
when build processes change, things like this may happen. I just hope
0.97.5 wasn't released with someone knowing that the database files were
empty. That to me is negligent.
I agree with Jim as well that I don't see a reason to change. If there's
a reason to change that we're not aware of, simply let us know *ahead of
time* so that we can make changes accordingly.
Thanks for your consideration, and your work on clamav.
Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net