Greetings.

I submitted a while ago a review request for a new spec for clamav in
EPEL. So far I haven't gotten any reviewers interested in it...

https://bugzilla.redhat.com/show_bug.cgi?id=396171

If anyone would like to review it that would be great.

I would be happy to also trade reviews.

It would be nice to get this in so EPEL has a nice new up to date and
working clamav.

kevin
_______________________________________________
epel-devel-list mailing list
epel-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/epel-devel-list

On Dec 5, 2007 11:31 AM, Kevin Fenzi <kevin@tummy.com> wrote:
> Greetings.
>
> I submitted a while ago a review request for a new spec for clamav in
> EPEL. So far I haven't gotten any reviewers interested in it...
>
> https://bugzilla.redhat.com/show_bug.cgi?id=396171
>
> If anyone would like to review it that would be great.
>
> I would be happy to also trade reviews.
>
> It would be nice to get this in so EPEL has a nice new up to date and
authorize> working clamav.
>

Ok... my opinions aren't going to be the greatest as I am really out
of practice.. but here are some general questions

1) Is massive perl patches ok for Fedora packages or is it better to
generate the patch as a file and apply it directly. When I do it
myself, I prefer the second as it doesnt break my auto-buildsystem as
much as pulling in perl etc when I don't need it.

2) file creation from inside of the SPEC. Is it better to have them as
seperate files or use cat inside the SPEC? Again.. I prefer seperate
files.. but I can understand having it in the spec means fix once
versus remember to fix a file you forgot about.

3) The generation of the UID is using whatever useradd gives it. Does
this fit in with the Fedora/EPEL standards?






--
Stephen J Smoogen. -- CSIRT/Linux System Administrator
How far that little candle throws his beams! So shines a good deed
in a naughty world. = Shakespeare. "The Merchant of Venice"

_______________________________________________
epel-devel-list mailing list
epel-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/epel-devel-list

On Wed, 5 Dec 2007 14:13:35 -0700
smooge@gmail.com ("Stephen John Smoogen") wrote:

> On Dec 5, 2007 11:31 AM, Kevin Fenzi <kevin@tummy.com> wrote:
> > Greetings.
> >
> > I submitted a while ago a review request for a new spec for clamav
> > in EPEL. So far I haven't gotten any reviewers interested in it...
> >
> > https://bugzilla.redhat.com/show_bug.cgi?id=396171
> >
> > If anyone would like to review it that would be great.
> >
> > I would be happy to also trade reviews.
> >
> > It would be nice to get this in so EPEL has a nice new up to date
> > and
> authorize> working clamav.
> >
>
> Ok... my opinions aren't going to be the greatest as I am really out
> of practice.. but here are some general questions

All feedback welcome. Happy to answer...

> 1) Is massive perl patches ok for Fedora packages or is it better to
> generate the patch as a file and apply it directly. When I do it
> myself, I prefer the second as it doesnt break my auto-buildsystem as
> much as pulling in perl etc when I don't need it.

There isn't any guideline either way. I usually prefer to use patches
myself, but this spec is based on one from Dag, and he used the perl
substitutions in there, so I left it in order to keep close to his spec.
As far as I know there is no guideline prohibiting this...

> 2) file creation from inside of the SPEC. Is it better to have them as
> seperate files or use cat inside the SPEC? Again.. I prefer seperate
> files.. but I can understand having it in the spec means fix once
> versus remember to fix a file you forgot about.

Yeah, again it's a matter of taste. I don't think there is any
guideline about which way to do things. Also again, I perfer seperate
files, but am keeping it this way to stay close to the Dag spec.

> 3) The generation of the UID is using whatever useradd gives it. Does
> this fit in with the Fedora/EPEL standards?

Yes. See:
http://fedoraproject.org/wiki/Packaging/UsersAndGroups

The idea is that if you need a user to be a specific uid, you can
already create that user with your fixed uid. This package checks when
you install and if the user is already there it leaves it alone. If you
don't care, one is created when this package is first installed.

kevin

_______________________________________________
epel-devel-list mailing list
epel-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/epel-devel-list

Kevin Fenzi wrote:


1) Is massive perl patches ok for Fedora packages or is it better to
generate the patch as a file and apply it directly. When I do it
myself, I prefer the second as it doesnt break my auto-buildsystem as
much as pulling in perl etc when I don't need it.



There isn't any guideline either way. I usually prefer to use patches
myself, but this spec is based on one from Dag, and he used the perl
substitutions in there, so I left it in order to keep close to his spec.
As far as I know there is no guideline prohibiting this...

It probably takes more resources in the builder to do a bunch of perl
stuff then using sed which probably in turn takes more then a simple
patch, but all methods are accepted and as long as it not confusing, all
of them are acceptable. Just use whatever you feel comfortable with.




2) file creation from inside of the SPEC. Is it better to have them as
seperate files or use cat inside the SPEC? Again.. I prefer seperate
files.. but I can understand having it in the spec means fix once
versus remember to fix a file you forgot about.



Yeah, again it's a matter of taste. I don't think there is any
guideline about which way to do things. Also again, I perfer seperate
files, but am keeping it this way to stay close to the Dag spec.


There is no specific guideline, AFAIK.
However I too almost always prefer to have separate files because you
can then use rpm for management (compare access times, avoid overwriting
modified files etc)
In this case I would be very much in favor of separate files, including
the script for updating signatures. I do not think that compatibility
with Dag's version is a big issue here.


_______________________________________________
epel-devel-list mailing list
epel-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/epel-devel-list

On Wed, Dec 05, 2007 at 07:39:51PM -0700, Kevin Fenzi wrote:
> There isn't any guideline either way. I usually prefer to use patches
> myself, but this spec is based on one from Dag, and he used the perl
> substitutions in there, so I left it in order to keep close to his spec.

So EPEL clamav is going to look like Dag's, not like the "regular"
Fedora clamav?

I'm not really a fan of the Fedora clamav packages, but I do have to
live with them (for amavisd-new). How much pain is this fork going to
cause me?

Honestly, I think I'd rather volunteer to maintain Enrico's clamav spec
in EPEL than even think about maintaining forked amavisd-new specs.

Steve
--
Steven Pritchard - K&S Pritchard Enterprises, Inc.
Email: steve@kspei.com http://www.kspei.com/
Phone: (618)624-4440 Mobile: (618)567-7320

_______________________________________________
epel-devel-list mailing list
epel-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/epel-devel-list

On Dec 6, 2007 10:26 AM, Steven Pritchard <steve@silug.org> wrote:
> On Wed, Dec 05, 2007 at 07:39:51PM -0700, Kevin Fenzi wrote:
> > There isn't any guideline either way. I usually prefer to use patches
> > myself, but this spec is based on one from Dag, and he used the perl
> > substitutions in there, so I left it in order to keep close to his spec.
>
> So EPEL clamav is going to look like Dag's, not like the "regular"
> Fedora clamav?
>

Yes.. this was discussed several times in the past. Part of it was
that a lot of enterprise people use dag's as it was there first and it
works with what they had.. second it was a peace offering in some
ways to try and say 'look' we are looking to work with others by using
what is 'best' for enterprise environments. Third.. this started at a
time when enrico was not going to push past 0.87 for some technical
reasons and DAG had 0.91 or so that people were needing for audits and
such.


> I'm not really a fan of the Fedora clamav packages, but I do have to
> live with them (for amavisd-new). How much pain is this fork going to
> cause me?
>
> Honestly, I think I'd rather volunteer to maintain Enrico's clamav spec
> in EPEL than even think about maintaining forked amavisd-new specs.
>

I would prefer to see how much work it was. I

--
Stephen J Smoogen. -- CSIRT/Linux System Administrator
How far that little candle throws his beams! So shines a good deed
in a naughty world. = Shakespeare. "The Merchant of Venice"

_______________________________________________
epel-devel-list mailing list
epel-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/epel-devel-list

On Thu, 06 Dec 2007 11:05:13 +0200
wolfy@nobugconsulting.ro (Manuel Wolfshant) wrote:

> In this case I would be very much in favor of separate files,
> including the script for updating signatures. I do not think that
> compatibility with Dag's version is a big issue here.

Well, I could easily split those out if a reviewer pressed on that
point enough. I prefer that usually as well.

kevin

_______________________________________________
epel-devel-list mailing list
epel-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/epel-devel-list

On Thu, 6 Dec 2007 11:26:46 -0600
steve@silug.org (Steven Pritchard) wrote:

> On Wed, Dec 05, 2007 at 07:39:51PM -0700, Kevin Fenzi wrote:
> > There isn't any guideline either way. I usually prefer to use
> > patches myself, but this spec is based on one from Dag, and he used
> > the perl substitutions in there, so I left it in order to keep
> > close to his spec.
>
> So EPEL clamav is going to look like Dag's, not like the "regular"
> Fedora clamav?

Thats my hope.

> I'm not really a fan of the Fedora clamav packages, but I do have to
> live with them (for amavisd-new). How much pain is this fork going to
> cause me?

I don't know, but I would love to hear. Do you want me to investigate?
Or can you take a look at the clamav packages and see?
I suspect this package would work with amavisd-new much easier than the
fedora one.

> Honestly, I think I'd rather volunteer to maintain Enrico's clamav
> spec in EPEL than even think about maintaining forked amavisd-new
> specs.

Can we see how much difference there would be first?
I would also be willing to co-maintain the epel amavisd-new if it would
help.

>
> Steve

kevin
_______________________________________________
epel-devel-list mailing list
epel-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/epel-devel-list