EPEL meeting summary/minutes - 2009-07-17
inode0 at gmail.com
Sat Jul 18 22:07:28 UTC 2009
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:
>> 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.
> I'm not going to answer all your comments responding to particular
> lines out of the irc log, as I don't think thats going to be
I doubt any further discussion will be productive and I'm willing to
just accept we don't agree on either the merits of repotags or the
benefits to EPEL using them.
> How about we list up the pros and cons and see if they are worth it?
> PRO: Easily end user visible marker for where a package came from.
> PRO: Other 3rd party repos use them, so people are used to them.
Joining that 3rd party community would have been a huge PRO when EPEL
had the chance. Now it is probably too late to list that as a PRO.
You can add or dismiss the other PROs given as part of the original
debate, I've got nothing new to add as I said before.
> CON: Causes us to diverge from Fedora
At least for packages targeted at RHEL users, diverging from making
your packages appear to users to be part of the distribution (which
makes them think they got them from Red Hat) goes in the PRO category,
not the CON category, from the perspective of the user.
> CON: Can be easily spoofed / isn't a sure indicator
Here we have the red herring for about the 5th time. This is
completely irrelevant to the vast majority of RHEL users unless EPEL
is going to lie about its repotag or unless Dag Wieers is going to lie
about his. I'd like to believe this is extremely unlikely to happen.
We have a trusted 3rd party community, trust that has been earned over
a number of years. Who do you think in that community is going to
spoof another repo's tags?
If such an unthinkable thing actually did happen it would be quickly
and easily discovered anyway.
> CON: Would require a mass rebuild of our packages.
> CON: Would need to be carefull this didn't change the upgrade path for
> users using multiple 3rd party repos, or at least notify them about it.
Both of these are the result of EPEL's previous decisions and you can
weigh them accordingly but they aren't CONs of repotags. The are just
CONs of EPEL changing to repotags now.
So from where I sit among RHEL users who occasionally need 3rd party
support I count zero CONs on your list aside from those that were
> (more to add for either list?)
> 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?
I'm not interested in searching and editing IRC logs and mailing lists
for you. You are now asking for too much effort from me when I see
almost no chance that anything would come from it.
There are several common cases that come up. One simple one is a user
has a problem with a particular package and its source needs to be
determined so they can report the bug or whatever. When rpm -q package
identifies the source everyone's life is just about as easy as it
could possibly be. If you find a simpler solution I'd love to hear
about it. Expecting someone providing help to ask that user to do what
Thorsten provided for 2 or 3 repos is not a simpler solution and is
really laughable. Yes, there are other ways we can extract the
information from the user, they take more time and effort on
As far as a script helping goes it would only help if it were provided
by Red Hat has part of RHEL. Otherwise it would not be available
universally as not everyone uses any particular 3rd party repo. And if
they (Red Hat) would agree to such a thing, unlikely I think, it might
as well be part of rpm, like rpm -q
More information about the epel-devel-list