Log from todays meeting
Dag Wieers
dag at wieers.com
Sat Jun 16 15:23:17 UTC 2007
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]
More information about the epel-devel-list
mailing list