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(a)wieers.com,
http://dag.wieers.com/ --
[all I want is a warm bed and a kind word and unlimited power]