On Mon, 2006-07-03 at 12:51 +0200, J.J.Garcia wrote: > Johnny Hughes wrote: > > On Mon, 2006-07-03 at 11:04 +0200, J.J.Garcia wrote: > > > >>Hi folks, > >> > >>Just updating clamav 'bundle' from old 'clamav-server' (i think the just > >>previous) and i noticed that the 'clamav' user/group for this pkg is not created > >>by default by the rpm pkg. > >> > >>At the same time, the /var/log/clamav is not updated/created with clamav.clamav > >>ownership, > >> > >>Don't know if it is my actual config (previous one untouched anyway), but this > >>is what i did to get it up and running in a CentOs 4.3 host > >> > >>Thanks for your ideas > >> > >>Jose > >> > > > > You are mixing 2 different clamav builds ... one is coming from Dag > > Wieers' EL4 repo ... the other is coming from KBS-CentOS-Extras repo. > > Dag's packages are built from the RPMForge spec file, KBS is built from > > a different spec file (from Fedora Extras). > > > > Both of these clamav builds work fine ... but they are different and > > don't work well together. > > > > Pick one repo to do clamav from ... in the other one, inside the repo > > definition for that repo, do this: > > > > exclude=clamd clamav* > > > > That should take care of dualing repo problems for clamav. > > > > Thanks, > > Johnny Hughes > > > > > > Is that a provisional issue? > > I mean, IMHO there's no point in maintaining this two releases of the same > thing/pkg in different repositories, unless you name them different to be > seleccted as appropiate (not exclude tag involved). > Well ... there are reasons, dependencies with other packages within the repo is the main one. Dag has his specs that work on many things ... then there is Fedora Extras (which is what KBS rebuilds) that are specifically for fedora. I'm sure Dag has his reasons for not using the Fedora Extras spec file ... and KBS is rebuilding Fedora Extras, so he needs it as a dependency to meet requirements. I don't think that we want repos where you have to have Dag _AND_ KBS enabled to meet requirements ... they should stand alone. (or at least have all reqts met with Base and the repo) ... That means that there will be overlap ... and that means there will be problem packages from time to time. > If so, how many pkgs are going to be like this way? It seems to me it could be a > nightmare, but this is only my opinion. Hints allowed. > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: <http://lists.centos.org/pipermail/centos/attachments/20060703/a5e549a9/attachment-0005.sig>