On Fri, Jul 17, 2009 at 5:04 PM, Kevin Fenzi<[email protected]> 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 _______________________________________________ epel-devel-list mailing list [email protected] https://www.redhat.com/mailman/listinfo/epel-devel-list
