EPEL meeting summary/minutes - 2009-07-17

[inode0]

On Sat, Jul 18, 2009 at 2:42 PM, Kevin Fenzi<kevin at tummy.com> wrote:
> On Fri, 17 Jul 2009 19:16:40 -0500
> inode0 <inode0 at gmail.com> wrote:
>
> ...snip...
>
>> Since I am one of the more vocal critics in #rhel on this subject I
>> guess I'll say my piece here now. The reason I haven't before,
>> although I have discussed it at some length with stahnma in #rhel, is
>> that I don't believe I have any new arguments to offer. I just am
>> persuaded by the arguments that are on the table already.
>
> ...snip...
>
> Personally, at this point I would like to know more about the end user
> cases you are seeing where a dist tag would help. Perhaps you could
> post some irc logs of users who this would have helped with (with the
> nicks redacted?). Can we do something else in these cases? Would a
> script help?

Here is another case that shouldn't come up but does. I install and
update a RHEL4 box, then install epel-release, run up2date -l and see

# up2date -l

Fetching Obsoletes list for channel: rhel-i386-as-4...

Fetching Obsoletes list for channel: EPEL...

Fetching rpm headers...
########################################

Name                                    Version              Rel
        Arch
----------------------------------------------------------------------------------------
gsl                                     1.10                10.el4
         i386

Now when that is included in a batch of legitimate updates from Red
Hat how is the user to have any idea this one isn't from Red Hat?
After the user updates this and Red Hat releases a security errata for
gsl that the user will miss how is the user supposed to know to track
this package for security issues from EPEL when he likely has no idea
it came from EPEL?

It does just seem like a good idea all around to me to make 3rd party
packages very obvious to the administrator.

John