BUG: clamav packages badly broken

[Florin Andrei]

Just a few quick observations:

I am trying to use clamd with amavis and Postfix. Amavis is supposed to 
pass the attachments to clamd via a Unix socket. That's how it worked 
for a while with the clamav packages made by Dag Wieers, no problems at all.

Today I uninstalled Dag's packages and installed the EPEL ones instead. 
Big mistake.

The /etc/init.d stuff is badly broken. There isn't even a script proper, 
there's just a symlink to a wrapper. The wrapper file is not in the 
recognized init.d scripts style.

There's a clamd.init file somewhere in /usr/share, but there's a 
<SERVICE> tag in it that needs to be adjusted. That same tag is somehow 
propagated in the clamd.sysconfig file and possibly in a buch of other 
places. No explanation for its purpose. The way it currently is, the 
scripts just fail.

Why is the package failing to work after install? Why it doesn't just 
work? Why the over-engineered customization with <SERVICE>?

There's a bunch of CLAMD_SERVICE variables sprinkled all over the place 
in the wrapper script, that appears to be related to the <SERVICE> tag. 
Holy freaking bejesus. Why should I care about that?
If I wanted to care about that, I would install clamav from source, 
thank you very much.

After installing clamav-server and the related packages, the stuff 
should Just Work (TM). It should not require dozens of obscure tweaks. 
What's the point in having a package otherwise?

The Dag packages simply worked, as they always do, perhaps with some 
small adjustments in the .conf file. I uninstalled them today, due to a 
conflict with EPEL and thought I could use the EPEL packages instead. 
How silly of me. If I can't figure out how to make the EPEL stuff work, 
I'll have to go back to Dag's packages and set up all kinds of 
exceptions in yum, to work around the broken EPEL packages.

How did these packages go through the verifications before being made 
public?

Meanwhile my mail server can either be offline, or without an antivirus. 
Merry Christmas. :-(

-- 
Florin Andrei

http://florin.myip.org/

[Devrim GÜNDÜZ]

Hi,

On Fri, 2007-12-28 at 13:47 -0800, Florin Andrei wrote:
>  Today I uninstalled Dag's packages and installed the EPEL ones
>  instead.  Big mistake. 
<snip>

+1. I'm sure that the packager has something in mind, but
configuring/starting clamd shouldn't take much time. I had the same
problem on Monday, and then reinstalled Dag's packages.

If there is no strong need for current layout, I suggest to move to the
old design.

Regards,
-- 
Devrim GÜNDÜZ , RHCE
PostgreSQL Replication, Consulting, Custom Development, 24x7 support
Managed Services, Shared and Dedicated Hosting
Co-Authors: plPHP, ODBCng - http://www.commandprompt.com/

[Michael Schwendt]

On Fri, 28 Dec 2007 13:47:31 -0800, Florin Andrei wrote:

>  Just a few quick observations: 
Funny. The differerent design of the Fedora clamav packages has been a
topic on various lists long ago. Actually, there's some rationale behind
the complexity of the Fedora clamav packages: packager's decision based on
security and versatility beyond basic clamav usage. The packages include
%doc files. You can't avoid reading them. The packages are not compatible
with Dag's packages. They have never been compatible with Dag's. This is
no secret. They do work, albeit differently than Dag's.

Unfortunately, the clamav users within the Fedora community have not cared
enough about clamav in Fedora as would be necessary to either a) reach a
consensus on how to package them, b) work with the original Fedora
packager on enhancing them with a more convenient setup procedure, or c)
do sufficient lobbying in order to convince Fedora Project leadership that
something is "wrong" with Fedora's clamav packages and may need
decision-finding on a higher level.

[Jon Ciesla]

>  On Fri, 28 Dec 2007 13:47:31 -0800, Florin Andrei wrote:
>
> > Just a few quick observations:
>
>  Funny. The differerent design of the Fedora clamav packages has been a
>  topic on various lists long ago. Actually, there's some rationale behind
>  the complexity of the Fedora clamav packages: packager's decision based on
>  security and versatility beyond basic clamav usage. The packages include
>  %doc files. You can't avoid reading them. The packages are not compatible
>  with Dag's packages. They have never been compatible with Dag's. This is
>  no secret. They do work, albeit differently than Dag's.
>
>  Unfortunately, the clamav users within the Fedora community have not cared
>  enough about clamav in Fedora as would be necessary to either a) reach a
>  consensus on how to package them, b) work with the original Fedora
>  packager on enhancing them with a more convenient setup procedure, or c)
>  do sufficient lobbying in order to convince Fedora Project leadership that
>  something is "wrong" with Fedora's clamav packages and may need
>  decision-finding on a higher level. 
Incidentally, I use clamav in production on fedora with sendmail.  No
issues.  Just had to make the socket paths in the config files match, and
voila.

>  _______________________________________________
>  epel-devel-list mailing list
>  epel-devel-list(a)redhat.com
>  https://www.redhat.com/mailman/listinfo/epel-devel-list
>  

-- 
novus ordo absurdum

[Stephen John Smoogen]

On Dec 28, 2007 5:10 PM, Michael Schwendt <bugs.michael(a)gmx.net&gt; wrote:
>  On Fri, 28 Dec 2007 13:47:31 -0800, Florin Andrei wrote:
>
>  > Just a few quick observations:
>
>  Funny. The differerent design of the Fedora clamav packages has been a
>  topic on various lists long ago. Actually, there's some rationale behind
>  the complexity of the Fedora clamav packages: packager's decision based on
>  security and versatility beyond basic clamav usage. The packages include
>  %doc files. You can't avoid reading them. The packages are not compatible
>  with Dag's packages. They have never been compatible with Dag's. This is
>  no secret. They do work, albeit differently than Dag's.
>
>  Unfortunately, the clamav users within the Fedora community have not cared
>  enough about clamav in Fedora as would be necessary to either a) reach a
>  consensus on how to package them, b) work with the original Fedora
>  packager on enhancing them with a more convenient setup procedure, or c)
>  do sufficient lobbying in order to convince Fedora Project leadership that
>  something is "wrong" with Fedora's clamav packages and may need
>  decision-finding on a higher level.
>  
I had a couple of conversations along the above. Enrico's position was
it worked for him and that other changes were not what he had in mind.
While it could have been the time I asked about (during one of the
flame wars), translation issues, or the reality of it.. it was pretty
much either his way or someone else maintain it and all his other
packages. Since that was not what I was looking for.. I decided to let
it rest.

There has been a push to patch the EPEL packages to be more like the
DAG clamav ones for 'various' reasons, but it has been held up in
review for quite some time.



-- 
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"

[Florin Andrei]

Michael Schwendt wrote:
>  
>  Funny. The differerent design of the Fedora clamav packages has been a
>  topic on various lists long ago. Actually, there's some rationale behind
>  the complexity of the Fedora clamav packages: 
They're not "complex". They're broken.

I can come up with countless examples of applications much more complex 
than clamav - their packages just work when installed.

Apache - it can do virtual hosts, reverse proxy and all sorts of fancy 
things. But the RPM package, once installed, Simply Works with a minimal 
setup. "service httpd start" launches a valid, working instance of the 
Apache server.
Want more than just the basics? Sure, knock yourself out, read the docs, 
change it.

Postfix - capable of doing virtual hosting, accounts via LDAP, the whole 
shebang. But the RPM package, once installed, launches an MTA with the 
basic functionality. You can surely tweak it to do a whole lot more. But 
initially it Simply Works: "service postfix start" and voila.

Clamav - install it, try to launch it, it fails. A lot of hacking is 
required to enable even the most basic functions. I cannot call that 
anything but broken.

>  The packages include
>  %doc files. You can't avoid reading them. 
Yes, I can, and I should - if all I want is the most basic 
functionality. An RPM package should just work, with the basic functions 
enabled, once it's installed. This is true for more than 99% of all the 
RPM packages out there.
For some reason, clamav is deemed to be a very special case, although 
there's nothing so special about this software to justify releasing an 
RPM package that does not work out of the box.

>  The packages are not compatible
>  with Dag's packages. They have never been compatible with Dag's. This is
>  no secret. 
Nobody asked for compatibility with Dag's, nor is that a reasonable request.

Asking for basic functionality to just work out of the box, though, is a 
reasonable request, which the current clamav packages in EPEL fail to meet.

>  They do work, albeit differently than Dag's. 
Not the packages I installed today, they don't. Proof: install them, 
then run "service clamav-wrapper start" (or whatever is the name of that 
broken symlink). Anything happened at all?

-- 
Florin Andrei

http://florin.myip.org/

[Florin Andrei]

Stephen John Smoogen wrote:
>  flame wars), translation issues, or the reality of it.. it was
> pretty
>  much either his way or someone else maintain it and all his other
>  packages. Since that was not what I was looking for.. I decided to let
>  it rest. 
I don't know what are the approval criteria, but the following test must 
be passed by any package containing a daemon (service) before it's released:

A package containing a daemon (service) must successfully execute 
"service daemon-init-script start" after the package has been installed. 
This command must launch a working instance of the daemon, with at least 
the basic functions enabled, the definition of "basic" depending on the 
daemon. No configuration changes should be required for that. Examples: 
Apache, Sendmail, Postfix, Squid.

-- 
Florin Andrei

http://florin.myip.org/

[Rex Dieter]

Florin Andrei wrote:


>  Clamav - install it, try to launch it, it fails. A lot of hacking is
>  required to enable even the most basic functions. I cannot call that
>  anything but broken. 
Bug filed?

-- Rex

[Dan Horák]

Florin Andrei píše v Pá 28. 12. 2007 v 19:20 -0800:
>  Stephen John Smoogen wrote:
>  > flame wars), translation issues, or the reality of it.. it was pretty
>  > much either his way or someone else maintain it and all his other
>  > packages. Since that was not what I was looking for.. I decided to let
>  > it rest.
>  
>  I don't know what are the approval criteria, but the following test must 
>  be passed by any package containing a daemon (service) before it's released:
>  
>  A package containing a daemon (service) must successfully execute 
>  "service daemon-init-script start" after the package has been installed. 
>  This command must launch a working instance of the daemon, with at least 
>  the basic functions enabled, the definition of "basic" depending on the 
>  daemon. No configuration changes should be required for that. Examples: 
>  Apache, Sendmail, Postfix, Squid.
>   
Sorry, but this is simply not true. I own 2 packages that will never
work like that. They need a manual configuration before they can be
started.


		Dan

[Ville Skyttä]

On Saturday 29 December 2007, Dan Horák wrote:
>  Florin Andrei píše v Pá 28. 12. 2007 v 19:20 -0800:
>  >
>  > I don't know what are the approval criteria, but the following test must
>  > be passed by any package containing a daemon (service) before it's
>  > released:
>  >
>  > A package containing a daemon (service) must successfully execute
>  > "service daemon-init-script start" after the package has been installed.
>  > This command must launch a working instance of the daemon, with at least
>  > the basic functions enabled, the definition of "basic" depending on the
>  > daemon. No configuration changes should be required for that. Examples:
>  > Apache, Sendmail, Postfix, Squid.
>
>  Sorry, but this is simply not true. I own 2 packages that will never
>  work like that. They need a manual configuration before they can be
>  started. 
Agreed.  If the service cannot be made to work out of the box without any 
manual configuration, so be it, but the init script should (must?) detect 
the "unconfigured" situation and output an understandable message what to do 
about it, possibly with a pointer to further documentation.  One example of 
this approach is in the init script of the Fedora vdr package.

[Michael Schwendt]

On Fri, 28 Dec 2007 18:38:29 -0700, Stephen John Smoogen wrote:

>  I had a couple of conversations along the above. Enrico's
> position was
>  it worked for him  
If the documentation files are followed, it does work, doesn't it?
And packages like exim-clamav do work, too?

Btw, I'm not sure that Enrico also maintains the packages in EPEL.

>  and that other changes were not what he had in mind.
>  While it could have been the time I asked about (during one of the
>  flame wars), translation issues, or the reality of it.. it was pretty
>  much either his way or someone else maintain it and all his other
>  packages. 
That's news to me that he wanted to drop all his packages. It would have
been even more reason to make it an important issue for one of the
relevant committees.

[Michael Schwendt]

On Fri, 28 Dec 2007 19:20:56 -0800, Florin Andrei wrote:

>  Stephen John Smoogen wrote:
>  > flame wars), translation issues, or the reality of it.. it was pretty
>  > much either his way or someone else maintain it and all his other
>  > packages. Since that was not what I was looking for.. I decided to let
>  > it rest.
>  
>  I don't know what are the approval criteria, but the following test must 
>  be passed by any package containing a daemon (service) before it's released:
>  
>  A package containing a daemon (service) must successfully execute 
>  "service daemon-init-script start" after the package has been installed. 
>  This command must launch a working instance of the daemon, with at least 
>  the basic functions enabled, the definition of "basic" depending on the 
>  daemon. No configuration changes should be required for that. Examples: 
>  Apache, Sendmail, Postfix, Squid. 
That's not a paragraph from the Fedora Review Guidelines [1]. Worded like
that it doesn't make much sense. It cannot be a MUST item. There are
daemon services, which do require configuration steps before they would no
longer refuse to start. It wouldn't be of much value to just create a
daemon for the fun of it, a dummy daemon (which does nothing or waits for
configuration file changes), or a daemon that actually relies on defaults
to start a very limited or even insecure service on localhost. Even with
defaults, some types of services may be missing configuration values until
they would do something useful. Not every value can be guessed (especially
not services which must know remote server addresses), and not every
default value is helpful either.

[1] http://fedoraproject.org/wiki/Packaging/ReviewGuidelines

[Michael Schwendt]

On Fri, 28 Dec 2007 19:16:27 -0800, Florin Andrei wrote:

>  Michael Schwendt wrote:
>  > 
>  > Funny. The differerent design of the Fedora clamav packages has been a
>  > topic on various lists long ago. Actually, there's some rationale behind
>  > the complexity of the Fedora clamav packages:
>  
>  They're not "complex". They're broken. 
Please don't just repeat complaints without substance.
 
>  > The packages include
>  > %doc files. You can't avoid reading them.
>  
>  Yes, I can, and I should - if all I want is the most basic 
>  functionality. An RPM package should just work, with the basic functions 
>  enabled, once it's installed.  
Then be the volunteer to provide a package that includes the configuration
files for such a "most basic" clamav daemon. AIUI, the Fedora clamav
packager doesn't want to provide such defaults because he thinks it would
be wrong to do that. The Fedora Package Collection is not closed, however,
it is open to the community.

>  > They do work, albeit differently than Dag's.
>  
>  Not the packages I installed today, they don't. Proof: install them, 
>  then run "service clamav-wrapper start" (or whatever is the name of that 
>  broken symlink). Anything happened at all? 
You are not supposed to run that. Read the documentation first.

[Stephen John Smoogen]

On Dec 29, 2007 6:16 AM, Michael Schwendt <bugs.michael(a)gmx.net&gt; wrote:

>  Then be the volunteer to provide a package that includes the configuration
>  files for such a "most basic" clamav daemon. AIUI, the Fedora clamav
>  packager doesn't want to provide such defaults because he thinks it would
>  be wrong to do that. The Fedora Package Collection is not closed, however,
>  it is open to the community.
>  
I think the issue is that in the past, Enricho has come across as his
way or someone maintains all of his packages. I am not sure if that
was his intent, but the feeling came across. Adding in a package for
basic configurations has been closed as a wontfix in the past.

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

>  > > They do work, albeit differently than Dag's.
>  >
>  > Not the packages I installed today, they don't. Proof: install them,
>  > then run "service clamav-wrapper start" (or whatever is the name of that
>  > broken symlink). Anything happened at all?
>
>  You are not supposed to run that. Read the documentation first.
>  
Why does every  time this package come up we end up with the same
comments... there seem to have been several more in the old
bugzilla.us one that I cant get to.

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

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

It is a different packaging philosophy that Enricho has.. but it does
seem to be different than most packages that Fedora ships. I am having
a hard time coming up with a mainstream package that does it that
way.. which I think is what causes the large amount of cognitive
dissonance, and harsh opinions when they come up.


-- 
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"

[Florin Andrei]

Michael Schwendt wrote:
>  
>  You are not supposed to run that. Read the documentation first. 
You are free to tell me what to do only _after_ you come up with a 
reasonable explanation as to why clamav is different from all other 
daemons out there and so it requires a different packaging philosophy. 
Until then, shut up.

-- 
Florin Andrei

http://florin.myip.org/

[Florin Andrei]

Rex Dieter wrote:
>  Florin Andrei wrote:
>  
>  
> > Clamav - install it, try to launch it, it fails. A lot of hacking is
> > required to enable even the most basic functions. I cannot call that
> > anything but broken.
>  
>  Bug filed? 
Good point.

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

-- 
Florin Andrei

http://florin.myip.org/

[Michael Schwendt]

On Sat, 29 Dec 2007 10:34:29 -0700, Stephen John Smoogen wrote:

>  Adding in a package for
>  basic configurations has been closed as a wontfix in the past.
>  
>  https://bugzilla.redhat.com/show_bug.cgi?id=161953 
Quote: 

| 'clamav-milter' itself should work out-of-the-box (after
| commenting out the 'Example' line in /etc/clamd.d/milter.conf);

Is that true? (I think requiring the admin to acknowledge an
example config file is not asked too much)

But I referred to the case the Fedora packager doesn't like: a single
system-wide clamd instance. Surely such a service can be provided in a
separate package, building on top of the clamav base (like the exim-clamav
package for Exim does it).

>  > > > They do work, albeit differently than Dag's.
>  > >
>  > > Not the packages I installed today, they don't. Proof: install them,
>  > > then run "service clamav-wrapper start" (or whatever is the name of
> that
>  > > broken symlink). Anything happened at all?
>  >
>  > You are not supposed to run that. Read the documentation first.
>  >
>  
>  Why does every  time this package come up we end up with the same
>  comments... 
Because everytime it comes up, it's ignorance that leads to the initial
complaints. Not all files in /etc/rc.d/init.d/ are service initscripts.
None of the documentation claims that one should start clamav like that.
Then, a person who complains is told about the need to complete
configuration files first (which sounds like an interactive helper-script
could aid with that), and the person still doesn't admit that the packages
work. Instead, it is repeated that those configuration steps should not be
necessary at all, and it is referred to a 3rd party package which starts a
single preconfigured daemon. The Fedora packager points out what he thinks
is wrong about starting a single clamd, and the discussion loops back to
the beginning.

That's why I suggest this issue is taken in front of a relevant Fedora
technical committee to decide on whether it is too complicated to set up
the packages and whether the packages fit into the Fedora Packaging
philosophy.

>  there seem to have been several more in the old
>  bugzilla.us one that I cant get to. 
The initial package reviews have not been straight-forward, especially not
since they contained technical problems and typos, which caused them to
malfunction and which lead to a series of questions and answers about
several aspects of the package design. For example, the purpose of the
sub-packages, "virtual packages" and "capabilities" was not obvious
or
lead to feedback.

At least one bigger thread should be on old fedora-extras-list.

>  It is a different packaging philosophy that Enricho has.. but it
> does
>  seem to be different than most packages that Fedora ships. I am having
>  a hard time coming up with a mainstream package that does it that
>  way.. which I think is what causes the large amount of cognitive
>  dissonance, and harsh opinions when they come up. 
Is setting up Samba or ntpd so much easier?

Heavy usage of virtual packages/capabilities in the clamav packaging may
be intimidating, but it boils down to a documentation issue (and the
package %descriptions explain quite a bit already).

[Kevin Fenzi]

On Fri, 28 Dec 2007 13:47:31 -0800
florin(a)andrei.myip.org (Florin Andrei) wrote:

>  Just a few quick observations:
>  
>  I am trying to use clamd with amavis and Postfix. Amavis is supposed
>  to pass the attachments to clamd via a Unix socket. That's how it
>  worked for a while with the clamav packages made by Dag Wieers, no
>  problems at all.
>  
>  Today I uninstalled Dag's packages and installed the EPEL ones
>  instead. Big mistake. 
Are you using amavis packages from dag? or amavisd-new from
epel/fedora? The two versions are very tied to the clamav version from
the same repo. 

>  Why is the package failing to work after install? Why it doesn't
> just 
>  work? Why the over-engineered customization with <SERVICE>? 
amavisd-new from fedora/epel should just work out of the box. 
It has the clamd start script in it due to the way the clamav package
in fedora is setup. 

>  After installing clamav-server and the related packages, the stuff 
>  should Just Work (TM). It should not require dozens of obscure
>  tweaks. What's the point in having a package otherwise? 
I would totally agree. 

>  ...snipp... 
>  How did these packages go through the verifications before being made
>
>  public? 
These have been in fedora for ages... 

>  Meanwhile my mail server can either be offline, or without an
>  antivirus. Merry Christmas. :-( 
:( 

So, let me recap what I know and perhaps someone will think of a
brilliant solution: 

- The fedora clamav maintainer wants to do things the way the package
is currently setup. They don't want to change it to be more simple/easy
to understand, or fix it to be more usable. This package meets all the
package guidelines. 

- I attempted to setup a clamav for epel that was based on the dag
rpms. However, amavisd-new, klamav, and other packages in fedora (and
thus epel) depend on clamav being packaged in the way that it is. This
would mean all those other packages would have to rework their specs
for the clamav package. 

- The amavisd-new maintainer in fedora/epel reluctantly agreed to
maintain the fedora version in EPEL. 

So, I don't see much way out... we go with the version currently in
fedora/epel, unless someone can talk the maintainer (and the
maintainers of all the dependent packages) into changing the package. 

Any other ideas? 

kevin

[Michael Schwendt]

On Sat, 29 Dec 2007 10:40:40 -0800, Florin Andrei wrote:

>  Michael Schwendt wrote:
>  > 
>  > You are not supposed to run that. Read the documentation first.
>  
>  You are free to tell me what to do only _after_ you come up with a 
>  reasonable explanation as to why clamav is different from all other 
>  daemons out there and so it requires a different packaging philosophy. 
>  Until then, shut up. 
"from all other daemons"? -> FUD.

[Florin Andrei]

Kevin Fenzi wrote:
>  
>  Are you using amavis packages from dag? or amavisd-new from
>  epel/fedora? The two versions are very tied to the clamav version from
>  the same repo. 
Dag. IIRC, his repo provided clamav, amavisd-new and stuff like that 
before Fedora / EPEL, and his packages always worked correctly, so I 
haven't even bothered to verify if such packages are available outside 
of dag.wieers.com. Until a few days ago, "yum update" failed on el5 due 
to a clamav conflict.

To make it clear, I'm not a dag.wieers.com partisan, I just want to use 
whatever software works and is easiest to use.

>  amavisd-new from fedora/epel should just work out of the box. 
>  It has the clamd start script in it due to the way the clamav package
>  in fedora is setup. 
>  These have been in fedora for ages... 
Oh great, that rot has been lingering there for ages and now other 
packages must work around the bug in the clamav packages. :-(

>  So, let me recap what I know and perhaps someone will think of a
>  brilliant solution: 
>  
>  - The fedora clamav maintainer wants to do things the way the package
>  is currently setup. They don't want to change it to be more simple/easy
>  to understand, or fix it to be more usable. This package meets all the
>  package guidelines. 
>  
>  - I attempted to setup a clamav for epel that was based on the dag
>  rpms. However, amavisd-new, klamav, and other packages in fedora (and
>  thus epel) depend on clamav being packaged in the way that it is. This 
awful

It's not that other packages have just to work around the broken clamav 
packages, but they need to make the assumption that the bug is there in 
order to be able to use clamav.

>  would mean all those other packages would have to rework their specs
>  for the clamav package. 
>  
>  - The amavisd-new maintainer in fedora/epel reluctantly agreed to
>  maintain the fedora version in EPEL. 
>  
>  So, I don't see much way out... we go with the version currently in
>  fedora/epel, unless someone can talk the maintainer (and the
>  maintainers of all the dependent packages) into changing the package. 
>  
>  Any other ideas?  
Back to using Dag's repo - setup all sorts of yum exceptions, so that 
the broken EPEL packages do not interfere with the good packages 
provided by Dag. Welcome to the repo hell. :-(

-- 
Florin Andrei

http://florin.myip.org/

[Florin Andrei]

Michael Schwendt wrote:
>  
>  Is setting up Samba or ntpd so much easier? 
Are you living in the same universe like everyone else?

ntp can be launched immediately after it's installed. "service ntpd 
start" and it's working already.

Samba may require setting up the workgroup at least, a couple more 
config items at most, then it's good to go. Or you can simply launch it 
as is and it will still work, albeit using the default workgroup. This 
is acceptable. This is very different from the situation with the EPEL 
clamav packages.

-- 
Florin Andrei

http://florin.myip.org/

[Manuel Wolfshant]

On 12/29/2007 09:34 PM, Florin Andrei wrote:
>  Back to using Dag's repo - setup all sorts of yum exceptions, so that 
>  the broken EPEL packages do not interfere with the good packages 
>  provided by Dag. Welcome to the repo hell. :-( 
That't exactly what
yum-priorities has been written for. Just setup 
rpmforge with a bigger priority over epel and you are done.

[Michael Schwendt]

On Sat, 29 Dec 2007 12:04:16 -0700, Kevin Fenzi wrote:

>  So, let me recap what I know and perhaps someone will think of a
>  brilliant solution: 
>  
>  - The fedora clamav maintainer wants to do things the way the package
>  is currently setup. They don't want to change it to be more simple/easy
>  to understand, or fix it to be more usable. This package meets all the
>  package guidelines. 
>  
>  - I attempted to setup a clamav for epel that was based on the dag
>  rpms. However, amavisd-new, klamav, and other packages in fedora (and
>  thus epel) depend on clamav being packaged in the way that it is. This
>  would mean all those other packages would have to rework their specs
>  for the clamav package. 
>  
>  - The amavisd-new maintainer in fedora/epel reluctantly agreed to
>  maintain the fedora version in EPEL. 
>  
>  So, I don't see much way out... we go with the version currently in
>  fedora/epel, unless someone can talk the maintainer (and the
>  maintainers of all the dependent packages) into changing the package. 
>  
>  Any other ideas?  
What exactly would make the current packages "more usable"?

Why can't a volunteer create and maintain a clamav configuration add-on
package, which offers a single system-wide clamav daemon if that is
requested by the clamav user base in Fedora/EPEL?

[Michael Schwendt]

On Sat, 29 Dec 2007 11:38:24 -0800, Florin Andrei wrote:

>  Michael Schwendt wrote:
>  > 
>  > Is setting up Samba or ntpd so much easier?
>  
>  Are you living in the same universe like everyone else?
>
>  ntp can be launched immediately after it's installed. "service ntpd 
>  start" and it's working already. 
Because these days a default setup is provided for it already at
firstboot-time (and hence the same defaults can be provided in the package
already, too). And it's a system-wide service.

# yum -y install openvpn
[...]
# service openvpn start
Starting openvpn:                                          [  OK  ]
# service openvpn start
Starting openvpn:                                          [  OK  ]
# service openvpn start
Starting openvpn:                                          [  OK  ]
[...]
# service openvpn status
openvpn: service not started
[...]
# service openvpn stop
Shutting down openvpn:                                     [  OK  ]
# service openvpn stop
Shutting down openvpn:                                     [  OK  ]
# service openvpn stop
Shutting down openvpn:                                     [  OK  ]

Hint: Read the initscript header to find out what is missing.

# yum -y install hddtemp
[...]
# service hddtemp start
Unconfigured: hddtemp, see /etc/sysconfig/hddtemp:         [FAILED]

>  Samba may require setting up the workgroup at least, a couple more 
>  config items at most, then it's good to go. Or you can simply launch it 
>  as is and it will still work, albeit using the default workgroup. This 
>  is acceptable. This is very different from the situation with the EPEL 
>  clamav packages. 
Ah, you would probably call the default openldap server setup
"acceptable", too...  truth is, these services require somebody to edit
the config files if you want more than an "[  OK  ]" to make you happy.

[Rahul Sundaram]

Kevin Fenzi wrote:

>  
>  I suppose someone could... thats not my issue however. My issues are in
>  the clamav package itself, not just not having a system wide clamd.  
Shouldn't this be brought up to the level of FESCo? Solving it only for 
EPEL if that is even possible seems the wrong solution to me.

Rahul

[Kevin Fenzi]

On Sat, 29 Dec 2007 21:38:10 +0100
bugs.michael(a)gmx.net (Michael Schwendt) wrote:

>  On Sat, 29 Dec 2007 12:04:16 -0700, Kevin Fenzi wrote:
...snip..
>  > Any other ideas? 
>  
>  What exactly would make the current packages "more usable"? 
Well, here is my list: 

- freshclam should work when the package is installed. Currently it
requires you to comment a line in a script for no reason I can tell. 

- freshclam should not mail "root,postmaster,webmaster,clamav" on any
output. 

- freshclam should be set to use your local country mirror for updates. 

- The milter should work with postfix. 

- The subpackages should be reduced and named in a way that an end user
could possibly know what they need to install for the functionality
they are looking for. For example, the upstream docs and every other
package talks about the 'freshclam' update program, it's not easy to
know that in fedora thats in the 'clamav-update' package. 

- The useless 'sysv' subpackages should be folded into the other
subpackages until such a time as fedora stops using sysvinit by
default.

- clamscan looks for a /etc/clamd.conf file for config options, which
is not in that place. If it was it wouldn't work because it needs a
line commented before it's a valid config file. 

- The package could not remove the clamav user on removal. 

I'm sure I could look around for more issues. 

>  Why can't a volunteer create and maintain a clamav configuration
>  add-on package, which offers a single system-wide clamav daemon if
>  that is requested by the clamav user base in Fedora/EPEL? 
I suppose someone could... thats not my issue however. My issues are in
the clamav package itself, not just not having a system wide clamd. 

kevin

[Michael Schwendt]

On Sat, 29 Dec 2007 14:06:13 -0700, Kevin Fenzi wrote:

>  - freshclam should work when the package is installed. Currently it
>  requires you to comment a line in a script for no reason I can tell.  
Cannot find this in bugzilla. The /etc/sysconfig script disables the automatic
update on purpose (to prevent unauthorized network access) and warns the
user about that default. What is wrong with that?
 
>  - freshclam should not mail
> "root,postmaster,webmaster,clamav" on any
>  output.  
Is this in bugzilla?
It also mails warnings and errors.
 
>  - freshclam should be set to use your local country mirror for
> updates.  
Is this in bugzilla?

>  - The milter should work with postfix.  
https://bugzilla.redhat.com/239037
 
>  - The subpackages should be reduced and named in a way that an end
> user
>  could possibly know what they need to install for the functionality
>  they are looking for. For example, the upstream docs and every other
>  package talks about the 'freshclam' update program, it's not easy to
>  know that in fedora thats in the 'clamav-update' package.  
Just a %doc issue so far, IMO. Unless it is ruled that clamav
must be in a single package.

>  - The useless 'sysv' subpackages should be folded into the
> other
>  subpackages until such a time as fedora stops using sysvinit by
>  default. 
https://bugzilla.redhat.com/322381 - WONTFIX

>  - clamscan looks for a /etc/clamd.conf file for config options,
> which
>  is not in that place. If it was it wouldn't work because it needs a
>  line commented before it's a valid config file. 
>  
>  - The package could not remove the clamav user on removal. 
>  
>  I'm sure I could look around for more issues. 
>  
>  > Why can't a volunteer create and maintain a clamav configuration
>  > add-on package, which offers a single system-wide clamav daemon if
>  > that is requested by the clamav user base in Fedora/EPEL?
>  
>  I suppose someone could... thats not my issue however. My issues are in
>  the clamav package itself, not just not having a system wide clamd.  
The list is interesting, but it adds more than what I thought has been the
primary (only?) issue with the Fedora clamav packages.

[Dag Wieers]

On Sat, 29 Dec 2007, lonely wolf wrote:

>  On 12/29/2007 09:34 PM, Florin Andrei wrote:
>
>  > Back to using Dag's repo - setup all sorts of yum exceptions, so that the
>  > broken EPEL packages do not interfere with the good packages provided by
>  > Dag. Welcome to the repo hell. :-(
>
>  That't exactly what yum-priorities has been written for. Just setup rpmforge
>  with a bigger priority over epel and you are done. 
Last time such a discussion popped up and I simply stated that RPMforge
and EPEL are not compatible and you are better off using only one of both
I was told to stop spreading FUD (by Rex Dieter).

Apparently it stopped being FUD today ?

-- 
--   dag wieers,  dag(a)wieers.com,  http://dag.wieers.com/   --
[Any errors in spelling, tact or fact are transmission errors]

[Ray Van Dolson]

On Sun, Dec 30, 2007 at 12:27:42AM +0100, Dag Wieers wrote:
>  On Sat, 29 Dec 2007, lonely wolf wrote:
>  
>  > On 12/29/2007 09:34 PM, Florin Andrei wrote:
>  >
>  > > Back to using Dag's repo - setup all sorts of yum exceptions, so that the
>  > > broken EPEL packages do not interfere with the good packages provided by
>  > > Dag. Welcome to the repo hell. :-(
>  >
>  > That't exactly what yum-priorities has been written for. Just setup rpmforge
>  > with a bigger priority over epel and you are done.
>  
>  Last time such a discussion popped up and I simply stated that RPMforge
>  and EPEL are not compatible and you are better off using only one of both
>  I was told to stop spreading FUD (by Rex Dieter).
>  
>  Apparently it stopped being FUD today ?
>   
I would say they most certainly are _not_ copmatible. :)  I don't use
EPEL's clam packages either and instead use exclude/includepkgs to pull
them in from rpmforge explicitly.

Kind of a mess, but hey it works. :)

Ray

[Stephen John Smoogen]

On Dec 29, 2007 2:06 PM, Rahul Sundaram <sundaram(a)fedoraproject.org&gt; wrote:
>  Kevin Fenzi wrote:
>
>  >
>  > I suppose someone could... thats not my issue however. My issues are in
>  > the clamav package itself, not just not having a system wide clamd.
>
>  Shouldn't this be brought up to the level of FESCo? Solving it only for
>  EPEL if that is even possible seems the wrong solution to me.
>  
It probably should, how does one do so.

-- 
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"

[Stephen John Smoogen]

On Dec 29, 2007 4:27 PM, Dag Wieers <dag(a)wieers.com&gt; wrote:
>  On Sat, 29 Dec 2007, lonely wolf wrote:
>
>  > On 12/29/2007 09:34 PM, Florin Andrei wrote:
>  >
>  > > Back to using Dag's repo - setup all sorts of yum exceptions, so that the
>  > > broken EPEL packages do not interfere with the good packages provided by
>  > > Dag. Welcome to the repo hell. :-(
>  >
>  > That't exactly what yum-priorities has been written for. Just setup rpmforge
>  > with a bigger priority over epel and you are done.
>
>  Last time such a discussion popped up and I simply stated that RPMforge
>  and EPEL are not compatible and you are better off using only one of both
>  I was told to stop spreading FUD (by Rex Dieter).
>
>  Apparently it stopped being FUD today ?
>  
I do not know. FUD is an overused acronym and probably is a corollary
to Godwin's law. It also depends on the tone and how it was said.
Email is not a medium to give tone or meaning to statements.. it is a
medium for partisan bickering. This is not an issue that can be solved
in a one paragraph email. It is a problem that will take a multi-line
sets of emails and people reasonably listening to each other, asking
for clarifications, and working towards and accepting an 'imperfect'
middle ground.


-- 
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"

[Jesse Keating]

On Sat, 29 Dec 2007 17:35:40 -0700
"Stephen John Smoogen" <smooge(a)gmail.com&gt; wrote:

>  It probably should, how does one do so. 
http://fedoraproject.org/wiki/Development/Schedule/MeetingGuidelines

-- 
Jesse Keating
Fedora -- All my bits are free, are yours?

[Stephen John Smoogen]

On Dec 29, 2007 11:40 AM, Florin Andrei <florin(a)andrei.myip.org&gt; wrote:
>  Michael Schwendt wrote:
>  >
>  > You are not supposed to run that. Read the documentation first.
>
>  You are free to tell me what to do only _after_ you come up with a
>  reasonable explanation as to why clamav is different from all other
>  daemons out there and so it requires a different packaging philosophy.
>  Until then, shut up.
>  
Comments like this one and others do not help get a fix. They just
stir emotional hot-buttons that make sure that fixes don't happen. Yes
clamav in EPEL/Fedora is not packaged the way that other repositories
do it. It causes conflicts and other issues and does not seem to be
what people expect out of a system service. However, every thread that
has started like this one has has just made the package more stuck in
the way it is.

So while we work out human issues on our part (which will take as long
as any EU debate..) how can we get your system working again. My first
suggestion would be to back out the clamav from EPEL and also figure
out what packages you are wanting from each repository.. and why.
Second put in yum-priorities to put each repository at a level... its
not a great fix.. having 'local' repos is a better fix but that is
outside the scope of this email.

-- 
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"

[Florin Andrei]

Dag Wieers wrote:
>  On Sat, 29 Dec 2007, lonely wolf wrote:
>  
> > On 12/29/2007 09:34 PM, Florin Andrei wrote:
> >
> >> Back to using Dag's repo - setup all sorts of yum exceptions, so that the
> >> broken EPEL packages do not interfere with the good packages provided by
> >> Dag. Welcome to the repo hell. :-(
> > That't exactly what yum-priorities has been written for. Just setup rpmforge
> > with a bigger priority over epel and you are done.
>  
>  Last time such a discussion popped up and I simply stated that RPMforge
>  and EPEL are not compatible and you are better off using only one of both
>  I was told to stop spreading FUD (by Rex Dieter).
>  
>  Apparently it stopped being FUD today ? 
"FUD" is probably an exaggeration.

yum-priorities is pretty damn ugly, and probably requires constant 
fiddling. But it may just work. No, I don't like it at all. But when 
it's the only solution... (shrug)

-- 
Florin Andrei

http://florin.myip.org/

[Florin Andrei]

Michael Schwendt wrote:
>  
>  Why can't a volunteer create and maintain a clamav configuration add-on
>  package, which offers a single system-wide clamav daemon if that is
>  requested by the clamav user base in Fedora/EPEL? 
That sounds good enough. Still not perfect, but it's something that can 
be lived with.

-- 
Florin Andrei

http://florin.myip.org/

[Florin Andrei]

Florin Andrei wrote:
>  Michael Schwendt wrote:
> >
> > Why can't a volunteer create and maintain a clamav configuration add-on
> > package, which offers a single system-wide clamav daemon if that is
> > requested by the clamav user base in Fedora/EPEL?
>  
>  That sounds good enough. Still not perfect, but it's something that can 
>  be lived with. 
By the way, the _name_ of the package is important. I'm not picking nits 
(I hope), I'm just thinking of the poor souls who might get trapped by 
the existing clamav packages and break their systems. It should be 
something that is self-explanatory when looking at the list provided by 
"yum install clamav\*"

"clamav-standalone-daemon" or something like that.

-- 
Florin Andrei

http://florin.myip.org/

[Devrim GÜNDÜZ]

Hi,

On Sat, 2007-12-29 at 10:17 +0100, Dan Horák wrote:
>  > A package containing a daemon (service) must successfully
> execute 
>  > "service daemon-init-script start" after the package has been
>  installed. 
>  > This command must launch a working instance of the daemon, with at
>  least 
>  > the basic functions enabled, the definition of "basic" depending on
>  the 
>  > daemon. No configuration changes should be required for that.
>  Examples: 
>  > Apache, Sendmail, Postfix, Squid.
>  > 
>  
>  Sorry, but this is simply not true. I own 2 packages that will never
>  work like that. They need a manual configuration before they can be
>  started. 
So your package must be fixed, too.

Regards,
--
Devrim GÜNDÜZ , RHCE
PostgreSQL Replication, Consulting, Custom Development, 24x7 support
Managed Services, Shared and Dedicated Hosting
Co-Authors: plPHP, ODBCng - http://www.commandprompt.com/

[Kevin Fenzi]

On Sat, 29 Dec 2007 22:40:22 +0100
bugs.michael(a)gmx.net (Michael Schwendt) wrote:

>  On Sat, 29 Dec 2007 14:06:13 -0700, Kevin Fenzi wrote:
>  
>  > - freshclam should work when the package is installed. Currently it
>  > requires you to comment a line in a script for no reason I can
>  > tell. 
>  
>  Cannot find this in bugzilla. The /etc/sysconfig script disables the
>  automatic update on purpose (to prevent unauthorized network access)
>  and warns the user about that default. What is wrong with that? 
Where is there a requirement that network access should require
configuration changes? Should we modify any other network accessing
services to require a config change before using the network?

What good would clamav be on a machine thats not on a network and what
good is it with no up 2 date virus definitions? 

>  > - freshclam should not mail
> "root,postmaster,webmaster,clamav" on
>  > any output. 
>  
>  Is this in bugzilla?
>  It also mails warnings and errors. 
No, I can file it I suppose. 

>  > - freshclam should be set to use your local country mirror for
>  > updates. 
>  
>  Is this in bugzilla? 
No. I can file it I suppose. 

>  > - The milter should work with postfix. 
>  
>  https://bugzilla.redhat.com/239037 
yeah. 

>  > - The subpackages should be reduced and named in a way that an
> end
>  > user could possibly know what they need to install for the
>  > functionality they are looking for. For example, the upstream docs
>  > and every other package talks about the 'freshclam' update program,
>  > it's not easy to know that in fedora thats in the 'clamav-update'
>  > package. 
>  
>  Just a %doc issue so far, IMO. Unless it is ruled that clamav
>  must be in a single package. 
Well, I agree it's a matter of package maintainers desires, but I don't
think all the docs in the world will help. This thread is proof of
that. 

>  > - The useless 'sysv' subpackages should be folded into
> the other
>  > subpackages until such a time as fedora stops using sysvinit by
>  > default.
>  
>  https://bugzilla.redhat.com/322381 - WONTFIX 
Yep. 

>  > - clamscan looks for a /etc/clamd.conf file for config options,
>  > which is not in that place. If it was it wouldn't work because it
>  > needs a line commented before it's a valid config file.  
I guess I should file this as well. 

>  > - The package could not remove the clamav user on removal. 
This I guess is part of the fedora-usermanagement setup. 

>  > I'm sure I could look around for more issues. 
>  > 
>  > > Why can't a volunteer create and maintain a clamav configuration
>  > > add-on package, which offers a single system-wide clamav daemon if
>  > > that is requested by the clamav user base in Fedora/EPEL?
>  > 
>  > I suppose someone could... thats not my issue however. My issues
>  > are in the clamav package itself, not just not having a system wide
>  > clamd. 
>  
>  The list is interesting, but it adds more than what I thought has
>  been the primary (only?) issue with the Fedora clamav packages. 
Really? So the only real issue you see is that there is no system wide
clamd setup? 

kevin

[Michael Schwendt]

On Mon, 31 Dec 2007 11:30:37 -0700, Kevin Fenzi wrote:

>  On Sat, 29 Dec 2007 22:40:22 +0100
>  bugs.michael(a)gmx.net (Michael Schwendt) wrote:
>  
>  > On Sat, 29 Dec 2007 14:06:13 -0700, Kevin Fenzi wrote:
>  > 
>  > > - freshclam should work when the package is installed. Currently it
>  > > requires you to comment a line in a script for no reason I can
>  > > tell. 
>  > 
>  > Cannot find this in bugzilla. The /etc/sysconfig script disables the
>  > automatic update on purpose (to prevent unauthorized network access)
>  > and warns the user about that default. What is wrong with that?
>  
>  Where is there a requirement that network access should require
>  configuration changes? 
It's not mandatory, but it's nice to the user.

>  Should we modify any other network accessing
>  services to require a config change before using the network? 
Installation of a package should not enable a network-using service
automatically. Accessing the network to download data may be seen as a
lesser problem than binding a service to a public port. But both are issues
where the user/admin ought to opt-in rather than opt-out.

>  What good would clamav be on a machine thats not on a network and
> what
>  good is it with no up 2 date virus definitions?  
This question is biased. The update feature is not missing, it can be
enabled for automated downloads if the software is told to do that.
 
>  > > - The package could not remove the clamav user on removal.
>
>  
>  This I guess is part of the fedora-usermanagement setup.  
uid/gid removal IMO is a "must not" unless all files with that uid/gid are
removed as well.

>  > > I'm sure I could look around for more issues. 
>  > > 
>  > > > Why can't a volunteer create and maintain a clamav configuration
>  > > > add-on package, which offers a single system-wide clamav daemon if
>  > > > that is requested by the clamav user base in Fedora/EPEL?
>  > > 
>  > > I suppose someone could... thats not my issue however. My issues
>  > > are in the clamav package itself, not just not having a system wide
>  > > clamd. 
>  > 
>  > The list is interesting, but it adds more than what I thought has
>  > been the primary (only?) issue with the Fedora clamav packages.
>  
>  Really? So the only real issue you see is that there is no system wide
>  clamd setup?  
 Yes, based on older [similar threads] that was my impression. The typical
clamav-in-fedora critic complains that starting clamd takes more than
installing the package and running a service script. It is certainly not
the first time somebody tried to run the wrapper-script without even
skimming over the readme file.

[Steven Pritchard]

On Mon, Dec 31, 2007 at 08:07:27PM +0100, Michael Schwendt wrote:
>  Installation of a package should not enable a network-using service
>  automatically. 
Doesn't yum-updatesd?

Steve
-- 
Steven Pritchard - K&S Pritchard Enterprises, Inc.
Email: steve(a)kspei.com             http://www.kspei.com/
Phone: [phone]               Mobile: [phone]

[Stephen John Smoogen]

On Jan 1, 2008 9:10 PM, Steven Pritchard <steve(a)silug.org&gt; wrote:
>  On Mon, Dec 31, 2007 at 08:07:27PM +0100, Michael Schwendt wrote:
>  > Installation of a package should not enable a network-using service
>  > automatically.
>
>  Doesn't yum-updatesd?
>  
Yes and other packages (many more in the past)... it is a line that
core packages seem to fall on both sides of. Do not turn on unless
there is a network, do not run if there isn't a general configuration,
do not have a configuration unless it is useful out-of-the-box for a
large segment.

-- 
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"

[Michael Schwendt]

On Tue, 1 Jan 2008 21:13:49 -0700, Stephen John Smoogen wrote:

>  On Jan 1, 2008 9:10 PM, Steven Pritchard <steve(a)silug.org&gt;
> wrote:
>  > On Mon, Dec 31, 2007 at 08:07:27PM +0100, Michael Schwendt wrote:
>  > > Installation of a package should not enable a network-using service
>  > > automatically.
>  >
>  > Doesn't yum-updatesd? 
And together with the implementation and the metadata problems, it causes
quite some problems. I've seen many users who were annoyed when they found
out that yum refuses to run because something in the background blocked it.

Fortunately, here I cannot get it to start anymore currently (F-8):

# yum -y install yum-updatesd
# service yum-updatesd start
Starting yum-updatesd:                                     [  OK  ]
[...]
# service yum-updatesd start
Starting yum-updatesd:                                     [  OK  ]
[...]
# service yum-updatesd start
Starting yum-updatesd:                                     [  OK  ]
[...]
# service yum-updatesd status
yum-updatesd dead but subsys locked
#
# /usr/sbin/yum-updatesd -d
#

>  Yes and other packages (many more in the past)... 
There is absolutely no need to enable the service in the package
already. It could also be enabled by the installer or in firstboot code.
Currently, it's not that the service is started when the package is
installed, it is started only after reboot.

[Johnny Hughes]

Michael Schwendt wrote:
>  On Tue, 1 Jan 2008 21:13:49 -0700, Stephen John Smoogen wrote:
>  
> > On Jan 1, 2008 9:10 PM, Steven Pritchard <steve(a)silug.org&gt; wrote:
> >> On Mon, Dec 31, 2007 at 08:07:27PM +0100, Michael Schwendt wrote:
> >>> Installation of a package should not enable a network-using service
> >>> automatically.
> >> Doesn't yum-updatesd?
>  
>  And together with the implementation and the metadata problems, it causes
>  quite some problems. I've seen many users who were annoyed when they found
>  out that yum refuses to run because something in the background blocked it.
>  
>  Fortunately, here I cannot get it to start anymore currently (F-8):
>  
>  # yum -y install yum-updatesd
>  # service yum-updatesd start
>  Starting yum-updatesd:                                     [  OK  ]
>  [...]
>  # service yum-updatesd start
>  Starting yum-updatesd:                                     [  OK  ]
>  [...]
>  # service yum-updatesd start
>  Starting yum-updatesd:                                     [  OK  ]
>  [...]
>  # service yum-updatesd status
>  yum-updatesd dead but subsys locked
>  #
>  # /usr/sbin/yum-updatesd -d
>  #
>  
> > Yes and other packages (many more in the past)...
>  
>  There is absolutely no need to enable the service in the package
>  already. It could also be enabled by the installer or in firstboot code.
>  Currently, it's not that the service is started when the package is
>  installed, it is started only after reboot. 
OK ... people can argue about this until we are all blue in the face.

The real answer, however is what your customers want.

People who routinely do not give their customers what they want find
themselves without any customers.

SO, I would think long and hard about such flaming comments as I have
seen on this thread.

If you don't care much for/about your customers, eventually you won't
have to.

Thanks,
Johnny Hughes

[Michael Schwendt]

On Wed, 02 Jan 2008 06:46:35 -0600, Johnny Hughes wrote:

>  OK ... people can argue about this until we are all blue in the
> face.
>  
>  The real answer, however is what your customers want. 
Fedora is not a product that is sold to customers, so by definition there
are no Fedora customers.

There is only the relationship with RHEL in that Fedora is used as a
testbed in order to find out how to develop RHEL further. But RHEL
customers don't choose RHEL because they like Fedora.

For Clamav, the evaluation period is not over yet. Without a doubt, its
setup can be made much more convenient with helper scripts and even a GUI
for desktop users.

For services like yum-updated, it is possible to notify the user that the
service is disabled. By default, the service does not apply any updates
anyway, so further action from the user/admin is needed (such as
configuring the system or clicking onto a desktop notification icon and
enabling a service).

>  People who routinely do not give their customers what they want find
>  themselves without any customers.
>  
>  SO, I would think long and hard about such flaming comments as I have
>  seen on this thread.
>  
>  If you don't care much for/about your customers, eventually you won't
>  have to.

[Ray Van Dolson]

On Wed, Jan 02, 2008 at 02:48:21PM +0100, Michael Schwendt wrote:
>  On Wed, 02 Jan 2008 06:46:35 -0600, Johnny Hughes wrote:
>  
>  > OK ... people can argue about this until we are all blue in the face.
>  > 
>  > The real answer, however is what your customers want.
>  
>  Fedora is not a product that is sold to customers, so by definition there
>  are no Fedora customers. 
There are users however, and shouldn't it be your goal to make your
package as useable as it can be by as many users as possible -- taking
into account their feedback (no matter how combative it may seem to
the maintainer)?

Even if you don't consider "users" customers, the effects are the same.
People will go elsewhere to fufill their need.  And a packager that
says "whoop dee doo I don't care" maybe isn't the best maintainer for
that package. :)

Just my $0.02
Ray

[Michael Schwendt]

On Wed, 2 Jan 2008 06:23:22 -0800, Ray Van Dolson wrote:

>  On Wed, Jan 02, 2008 at 02:48:21PM +0100, Michael Schwendt wrote:
>  > On Wed, 02 Jan 2008 06:46:35 -0600, Johnny Hughes wrote:
>  > 
>  > > OK ... people can argue about this until we are all blue in the face.
>  > > 
>  > > The real answer, however is what your customers want.
>  > 
>  > Fedora is not a product that is sold to customers, so by definition there
>  > are no Fedora customers.
>  
>  There are users however, and shouldn't it be your goal to make your
>  package as useable as it can be by as many users as possible -- taking
>  into account their feedback (no matter how combative it may seem to
>  the maintainer)? 
That's not a question that can be answered with "yes" or "no".
First of
all, it's the "as many users as possible" that is too vague and makes it
difficult to answer. And secondly, if there are many users who are unhappy
with the package (and I refer to clamav as it has been in Fedora for a
long time, not specifically to EPEL, as EPEL has other requirements), why
don't any volunteers work on improving the packages? E.g. with an add-on
package for a system-wide daemon, helper scripts, patches and a task-force
that works together with the packager?

Feedback like "the clamav pkg is broken", which does not even try to
follow the short instructions in the package documentation, won't convince
the package maintainer.

It's not that the packager doesn't admit the manual configuration steps
are inconvenient. There may be other reasons (e.g. lack of time) why it is
still like that, and clamav add-on packages demonstrate how to set up
services on top of the base clamav packages. There is no bugzilla ticket
which clearly makes it a primary goal to improve/enhance/change the
packages in well-defined ways. User satisfaction is not tracked anywhere.
Every few months somebody tries to execute a non-executable script or
ignores the documentation. And meanwhile, nobody else contributes any
patches or co-maintainership. The packager is a volunteer like lots of the
other packagers. In case of severe disagreement between him and what some
people claim is a large portion of the clamav users it really may need
somebody from FESCo to look into it. So, please start filing tickets,
point out your concerns, get status updates from the maintainer, ...

>  Even if you don't consider "users" customers, the
> effects are the same.
>  People will go elsewhere to fufill their need.  And a packager that
>  says "whoop dee doo I don't care" maybe isn't the best maintainer for
>  that package. :) 
With all due respect, but that paragraph above is only cheap talk IMO,
which isn't helpful at all.

[Florin Andrei]

Michael Schwendt wrote:
>  
>  Fedora is not a product that is sold to customers, so by definition there
>  are no Fedora customers. 
Thank God for definitions - the perfect shelter against harsh, cold, 
inconvenient reality.

-- 
Florin Andrei

http://florin.myip.org/

[Kevin Fenzi]

On Wed, 2 Jan 2008 16:23:28 +0100
bugs.michael(a)gmx.net (Michael Schwendt) wrote:

>  ...snipp...
>  So, please start filing
>  tickets, point out your concerns, get status updates from the
>  maintainer, ... 
An excellent plan. I filed: 

https://bugzilla.redhat.com/show_bug.cgi?id=427103
https://bugzilla.redhat.com/show_bug.cgi?id=427104
https://bugzilla.redhat.com/show_bug.cgi?id=427105

To start with. 

Will see what the maintainer says on those. 

I think another thing that doesn't help here is that several of the
CLOSED->WONTFIX bugs against clamav refer readers to the fedora.us
bugzilla instance for reasoning, but that is no longer available. 

There are 15 closed->NOTABUG and 6 closed->WONTFIX bugs against clamav,
which I think is an indicator that users are confused by the packaging
and/or find it non intuitive. 

In any case, I think we should try and be constructive here. 
If anyone has other issues, please file them. If folks are seeing the
same above issues I am seeing and would like them fixed, please add
your comments to the above bugs. 

kevin