Log from todays meeting

[Dag Wieers]

On Wed, 13 Jun 2007, Thorsten Leemhuis wrote:

> 00:24 <         f13> | there is clearly a need to better identify where
> packages came from.  repo tags aren't the solution IMHO

True, but any solution proposed will not hit RHEL until RHEL6.

This is not Fedora where we can fix something for the next release a few 
months away. This Fedora mentality is really what is wrong with EPEL in my 
opinion. How many of you people are still using RHEL2.1 or RHEL3 ?

RHEL5 is the RHEL3 of 2010. No customer is interested in RHEL5 now if it 
will be ignored like RHEL3 is today.


> 00:24 <      smooge> | Ok, could there be a public reasoning statement
> about this to make it final. Basically, that EPEL is not meant to work
> with other repo's and that mixing/matching repo's is considered too much
> of a support burden for EPEL volunteers.

Please do. Because that's what we have seen being discussed in the EPEL 
meetings, but on the list the same viewpoint has not been defended. In 
fact it has been rebutted many times.


> 00:29 <         f13> | lancelan: Dag gave reasons why identifying where
> a package came from would be handy.  repodtags are a hacky way of
> accomplising that goal (kind of), but not one that FEdora is willing to
> use.  We'd rather find a more robust solution to the problem.

So we won't have a solution for RHEL2.1, RHEL3, RHEL4 or RHEL5. Because 
looking at new development is excluding the currently supported 
distributions. I'm willing to look at any alternative if we have one, but 
I'm more interested to implement something that we can use today. And 
repotags have been that solution.

f13 was not in the discussion at LinuxTag and apparently did not read some 
of my mails concerning repotags:

	http://www.redhat.com/archives/epel-devel-list/2007-May/msg00134.html
	http://www.redhat.com/archives/epel-devel-list/2007-May/msg00135.html

repotags make the package-name unique, which is important for a depsolver 
to understand what packages belong together. 


> 00:29              * | notting is confused. we have repo tags already.
> %{DISTRIBUTION} and %{PACKAGER}

Those do not make a package unique. Welcome to the discussion. A depsolver 
does not use the information and even if it could be made to do that, we 
won't have it in RHEL2.1, RHEL3, RHEL4 or RHEL5.

Please move any design work to RHEL6 in 2009. We are talking about the 
past and the presence.


> 00:29 <    mmcgrath> | smooge: the problem is that in the dag and axel
> world, the guys that run the show are also THEE packagers.  Thats not
> the case in EPEL.  I firmly believe that to fix this problem the
> packages have to change.  And the EPEL SIG just can't do that.

No, packages do not have to change. In fact, there is no repotag in the 
authoritative SPEC file, they are added by the buildsystem. We _have_ 
discussed that and Thorsten said it was a possibility, welcome to the 
discussion.


> 00:30 <    lancelan> | well it seems to me that the fedora camp is
> firmly entrenched against repotags ...
> 00:30 <    mmcgrath> | lancelan: but would you say "the fedora camp is
> firmly entrenched against 3rd party repos" ?

/me notes that EPEL is a 3rd party repository itself.


> 00:31 <    mmcgrath> | smooge: but you're binding repo tags and
> collaboration and thats a fallacy.

repotags are required for RHEL2.1 upto RHEL5 if you want to be able to mix 
repositories. If EPEL is against mixing repositories, please say so 
clearly.

And then we move back to the fact that different RHEL/CentOS users want 
different things, like maturity or latest. Which cannot possibly live in 
the same repository (unless we fix Yum to understand it) and hence we move 
into a subject that EPEL is desperately ignoring.

You'll have to mix repositories at some point because not all users 
want/need maturity. (whatever that is defined by)


> 00:32 <    mmcgrath> | repo tags will not fix the clamav problems, dag
> working with the clamav packager will.  And that has nothing to do with
> the SIG.

repotags would at least allow to upgrade from one version to another. 
Without repotags it wouldn't even be possible (as there may not be a 
distinction from RPM's point of view). I've explained this in our meeting 
and at least some people understood that repotags could help.

It won't fix all problems, but I doubt there is one solution that fixes 
all problems.


> 00:33 <      smooge> | mmcgrath, since I have joined it has been
> mentioned on both sides as being part of collaboration at some point or
> another.
> 00:33 <    lancelan> | I actually dont like repotags - and agree that
> yum/rpm should be able to indicate repo - but they dont ...
> 00:33 <      smooge> | I would like to see a definition in the end of
> what is collaboration and what can be done if anything to meet it
> 00:33 <    mmcgrath> | smooge: but collaboration does not mean "do what
> the other guy says"

Please come up with a workable proposal then ? Don't just refuse the idea 
without even understanding what I have been explaining.

And please understand that any workable proposal cannot touch RPM or Yum 
since we cannot replace those in RHEL5 and older.


> 00:34 <    lancelan> | unless of course you specifically ask
> 00:34 <         f13> | lancelan: they can, but it requires more query
> flags.  Now whether or not those query flags are made more prominent, or...

Please, do not talk about future development. We've been there, no 
solution for the past and present.


> 00:35 <       knurd> | does anybody really think opinions will cahnge if
> we discuss this further?
> 00:35 <      wwoods> | rpm -qi isn't that hard

Oh, it makes a difference between replying with a solution straight away 
and having to ask for additional information. On IRC that often means, a 
solution or no solution.

Besides, as soon as we have clamav packages with exactly the same EVNR, be 
sure that rpm -qi may not even give proper information, because 
clamav-0.90.2-3 and clamav-devel-0.90.2-3 could be from 2 DIFFERENT 
repositories. Querying one or the other may confuse you even more.


> 00:35 <         f13> | smooge: working with 3rd party repos is going to
> be pretty hard in any case.  THe EPEL project cannot reference nor link
> to these 3rd party repos for software, as those repos host illegal
> content.  SO we have to package everything we want in EPEL proper, which
> immediatly creates 'conflicts' with these 3rd party repos.

So EPEL is a 3rd party repository that does not work well with other 3rd 
party repositories ?


> 00:35 <         f13> | smooge: if these repos would just drop the
> illegal content then it would be much easier.

What is illegal to you, is not illegal to me. I do not live in the US and 
I do not want to be bound to US law. Other countries may even be stricter 
than US law.

It's not only problematic that US is lobbying for stricter laws all around 
the world, but using this forum and repositories to force US law on the 
rest of the world I find distasteful.


> 00:38 <         f13> | Jeff_S: the people that are complaining loudly
> about 'interoperability' with 3rd parties are the ones that are carrying
> things we can't reference.

So, we finally found an excuse for no colaboration. At least that means I 
wil have more time for not trying.

Kind regards,
--   dag wieers,  dag at wieers.com,  http://dag.wieers.com/   --
[all I want is a warm bed and a kind word and unlimited power]