Description of problem:

If someone patches a file in /etc/event.d/ (say foo), a backup file
(foo.orig) is created in the event.d directory. This causes
undesirable and confusing behaviour.

Version-Release number of selected component (if applicable):
upstart-0.3.9-24.fc11.x86_64

How reproducible:
Completely

Steps to Reproduce:
1. patch a file $f in /etc/event.d
2. reboot
3. initctl list | egrep $f
  
Actual results:
 shows two versions of the event, one called $f.orig

Expected results:
 should only show $f

Additional info:

What happened to me was that I wanted to make the same change to the
serial event, as I had on previous versions of Fedora. I keep such
things under version control, so I generated a patch from the old
system and applied it to the new.

The result was multiple agettys running on /dev/ttyS0, which made the
console unusable. Having detected that there was a problem (though not
knowing what it was) I edited /etc/event.d/serial to try something,
which also left serial~ in the directory. I'm not sure whether that
also produced an agetty (after a reboot there were three running. The
reboot was needed because I triggered the serial console available
event to test the change and this resulted in a daemon storm).

Question: what happens if someone edits an event.d file (taking care
to remove any backup copy) and later updates the rpm that owns the
file? If rpm renames the old to $f.rpmsave or renames the new to
$f.rpmnew, wouldn't that cause problems?

While one might argue that system administrators should be careful
about leaving backup files in /etc/event.d, it would seem preferable
to use the convention followed by various other subsystems and have
upstart only read /etc/event.d/*.event