EPEL meeting summary/minutes - 2009-07-17

inode0 inode0 at gmail.com
Sat Jul 18 00:16:40 UTC 2009


On Fri, Jul 17, 2009 at 5:04 PM, Kevin Fenzi<kevin at tummy.com> wrote:
> =============================
> #fedora-meeting: EPEL meeting
> =============================
>
> 21:42:35 <nirik> #topic Repotags Redux
> 21:42:48 <nirik> do we want to re-open the repotags debate?
> 21:43:04 <jds2001> yes, it has strong support from our users.
> 21:43:13 * jds2001 wasnt around for the previous one, though
> 21:43:31 <jds2001> but if you hang out in #rhel, you here about that a lot.

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.

> 21:43:39 * dgilmore says shut it in a closet and let it rot in its on hell

One of the things that bugs me about the repotag issue is that as the
new kid on the block EPEL had a choice to make. Is it going to join
the existing 3rd party repo community or just go its merry way and to
hell with the rest of the community. Comments like this reinforce my
perception that it decided to hell with the rest of the community.

I've never understood why EPEL is so strongly against doing something
that has a very low cost that others see value in whether EPEL sees
much value in it or not. Burning community bridges over something
fairly trivial doesn't seem to me to be the most productive way to
build a new community around EPEL.

> 21:43:40 <nirik> jds2001: oh? they have strong support for this, but don't know about incompatible upgrades? ;)
> 21:43:44 <Jeff_S> ... at this point I will abstain
> 21:43:56 <jds2001> nirik: yeah :/

Yeah, people in #rhel are pretty uneducated and have little experience
with using 3rd party repos with RHEL.

> 21:44:05 <nirik> jds2001: so what do people there ask? how they can tell if a package is from epel? how does it come up?
> 21:44:18 <jds2001> yes, that's one thing.
> 21:44:21 <stahnma> it comes up any time I mention epel
> 21:44:23 <stahnma> at all
> 21:44:23 <stahnma> ever
> 21:44:26 <stahnma> seriously
> 21:44:28 <maxamillion> yeah, I get yelled at a lot for EPEL not having repotags when I hang out in #rhel ... which is why I asked
> 21:44:41 <dgilmore> jds2001: id prefer to add a script to epel-release that prints all packages from epel that are installed
> 21:44:43 <maxamillion> on the mailing lists*
> 21:44:55 <jds2001> dgilmore: what's the reasoning against it?

People helping others with problems with a package don't want a
solution to this question to involve running a different program to
test for packages from each repo when a silly little tag is good
enough for the level of identification required for our purposes.

> 21:44:56 <nirik> stahnma: really? as in "oh, try the epel package of foo" "EPEL? REPOTAGS!!!!!!!!!!!!!!!!!!!!!!!" :)

Pretty much and these sorts of remarks are not making things better.

> 21:45:03 <maxamillion> dgilmore: that would honestly fix the complaints I've heard
> 21:45:05 <stahnma> nirik: basically
> 21:45:25 <maxamillion> nirik: close ... strangely close actually
> 21:45:31 <dgilmore> jds2001: ill talk to you about it outside of here
> 21:45:32 <stahnma> I think people want an easy way to see what repo packages came from
> 21:45:33 <nirik> it's a poor indicator of where a package is from.

Well, by what measure is it poor? I can check all the packages here
tagged with .rf and guess how many of them are not from RPMforge? This
isn't about determining with certainty where a package is from. That
almost never comes up in a community support venue.

> 21:45:37 <stahnma> in a massive view
> 21:45:42 <stahnma> like rpm -qa or yum list
> 21:45:51 <stahnma> only one that includes repo
> 21:45:59 <stahnma> I wrote something that does that using the GPG key value
> 21:46:11 <stahnma> but it's probably not foolproof
> 21:46:12 <inode0> no one wants to do that
> 21:46:26 <smooge> nirik I think a LOT of people just do the following to get into EPEL. Google for a package. Install epel-release. yum install. Oh look I need another pakcage. Its in rpmforge. Repeat
> 21:46:37 <stahnma> exactly
> 21:46:37 <dgilmore> nirik: right its not a win at all and easily faked

It would lose some of its value if it were widely faked. That isn't
the reality we live in though. RPMforge is not going to fake EPEL's
repotag. Most RHEL users are not installing random rpms they find on
the internet.

> 21:46:47 <nirik> smooge: sad. ;(
> 21:47:00 <stahnma> but very real (not in my shop though :) )
> 21:47:14 <smooge> I thought that it would be a minor thing.. but I had 40 computers at a government lab with different people following other advice
> 21:47:18 <nirik> stahnma: what would you think about adding your script to epel-release?
> 21:47:25 <dgilmore> stahnma: your special though, thats a well established fact :)
> 21:47:36 <Jeff_S> so let's wait for rhel 6 when yum will show repo in yum list? :)
> 21:47:39 <stahnma> it needs to be re-written.  It's currently in ruby and really kind of dumb
> 21:47:40 <Jeff_S> problem solved?
> 21:47:59 <nirik> ideally it would be nice for rhel to get a script/package to list that info
> 21:48:03 <smooge> Jeff_S, no because people do rpm -qa not yum list

People might do either but since yum doesn't exist on probably most
RHEL boxes it isn't going to be our first choice for some time.

> 21:48:22 <dgilmore> nirik: there is a script in rhel already
> 21:48:28 <stahnma> teh best solution is to have a tag/field in RPM for it

This might be the best solution in theory. But in practice it wouldn't
help as it would never find its way back to the installed base of RHEL
systems that exist now.

> 21:48:29 <Jeff_S> smooge: that's their own problem then and they'll find something else to complain about if there were dist tags

Don't worry, they complain about other things now like security issues
not getting resolved. To what extent that may or may not be a problem
I don't personally know, but I've heard that complaint too.

> 21:48:39 <dgilmore> nirik: the one that puts your system info together for gss
> 21:49:06 <dgilmore> stahnma: no because it can be faked
> 21:49:08 <nirik> dgilmore: oh? how to use? ;)
> 21:49:23 <jds2001> dgilmore: actually it might not be to bad as an sos plugin
> 21:49:37 <jds2001> but one that can be manually executed too.
> 21:49:46 <jds2001> nirik: sosreport
> 21:49:55 <dgilmore> nirik: sosreport

It is obnoxious enough when Red Hat support people ask for a
sosreport. It will be a very cold day in hell when community support
people will do that to answer a simple question.

> 21:50:08 <nirik> in any case I think education is better than repotags. ;)

On the one hand we can have a simple and consistent naming convention
of rpms from the major 3rd party repos with which we can efficiently
help users having problems or on the other hand we can be educated by
EPEL in how to deal with them as a special case. We have already
figured out how to deal with EPEL as a special case, no need for
further intervention.

> 21:50:15 <dgilmore> jds2001: right or even epelreport
> 21:50:16 <nirik> how about a wiki page on this stuff?
> 21:50:21 <nirik> we can point people to?
> 21:50:24 <dgilmore> that reports on installed epel packages
> 21:51:21 <maxamillion> dgilmore: I like that idea also
> 21:51:53 <dgilmore> stahnma: lets worktogether on putting something together
> 21:52:29 <maxamillion> I've gotta run
> 21:53:07 <stahnma> ok
> 21:53:17 <stahnma> I like the idea of reporting on all packages if possible
> 21:53:31 <stahnma> but epel vs core el for sure
> 21:53:36 <nirik> I think a wiki page or other place to point people would be good too. ;)
> 21:53:51 <nirik> just group them by gpg key. ;)
> 21:54:05 <nirik> anything else on this?
> 21:54:21 <smooge> no I have brought it up for the year of 2009
> 21:54:39 <nirik> #topic Open Floor
> 21:54:44 <nirik> smooge: :)
> 21:54:53 <nirik> anyone have anything else they would like to bring up?
> 21:55:38 <smooge> personally I like repotags, but I am not going to harp about it more than once a year. I will let someone else bring it up from #rhel next time.
> 21:56:57 <nirik> yeah, on a first glance I like them too, but then I realize how fakable/unreliable they are, so would prefer to have a better method.

How unreliable are they? They are very reliable on every box I manage.
This is a complete red herring.

> 21:57:12 <stahnma> I think it might do us some good to jump into #rhel and see what our users like/dislike about epel
> 21:57:18 <stahnma> and what we can do to make it more widely used
> 21:57:40 <nirik> stahnma: yeah, not a bad idea I guess. I'm already in a billion channels, I guess I can hang out there too.
> 21:58:16 * nirik will close out the meeting in 60seconds if nothing else comes up.
> 21:58:19 <stahnma> well, we certainly don't have to
> 21:58:23 <stahnma> oh, one more thing
> 21:58:27 <stahnma> who's going to the RH summit?
> 21:58:31 <stahnma> or we can bring it up next time
> 21:59:07 * nirik isn't planning on it.
> 21:59:24 <nirik> a EPEL bof or whatever there might be good though if we have enough people going.
> 21:59:49 <Jeff_S> OSCON?
> 22:00:02 <stahnma> I'm not at OSCON
> 22:00:07 <stahnma> but at the RH Summit
> 22:00:23 <smooge> I wont be at the Summit
> 22:00:51 <nirik> #endmeeting

John




More information about the epel-devel-list mailing list