Axel Thimm wrote:
On Fri, Dec 07, 2007 at 05:12:06PM -0600, Les Mikesell wrote:
But it would be even better if we could live with the assumption that repos
will have incompatibilities, whether accidental or intentional. Then it
would become a choice of which to install and things wouldn't
Am Sonntag, den 09.12.2007, 21:27 +0200 schrieb Axel Thimm:
...
I'll just repeat myself: If the packagers don't cooperate no technical
solution will be able to really cover compatibilty problems. You'll
paper over some of them and create a false feeling that you have
mastered the
On Sun, Dec 09, 2007 at 08:32:57PM +0100, Heiko Adams wrote:
Am Sonntag, den 09.12.2007, 21:27 +0200 schrieb Axel Thimm:
...
I'll just repeat myself: If the packagers don't cooperate no technical
solution will be able to really cover compatibilty problems. You'll
paper over some of them
Axel Thimm wrote:
Sorry, that's not possible. Just to give an example: For some reason
you favour repo A and make it trump over repo B. Both repos ship
libfoo and repo B ships also appbaz needing libfoo with a couple more
configure options turned on.
No smart package manager in the world will
On Sun, Dec 09, 2007 at 08:55:08PM +0100, Heiko Adams wrote:
Am Sonntag, den 09.12.2007, 21:39 +0200 schrieb Axel Thimm:
...
But what does that have to do with 3rd party repos A and B supporting
CentOS but being incompatible towards each other? This is not about
3rd party repos replacing
On Friday 07 December 2007, Karanbir Singh wrote:
I'd be happy to host the rest of this conversation in
[EMAIL PROTECTED] - which might actually have more people
watching who play a role in these situations ?
There is one point that belongs in the user CentOS list (and not on
centos-devel)
On Thu, Dec 06, 2007 at 02:57:11PM -0700, Stephen John Smoogen wrote:
However at some point people quit thinking logically and instead
started just throwing virtual dung at each other
Personally I think that oversimplifies the issue a lot. There was a
plea for cooperation from one side and a
Axel Thimm wrote:
So repotags was a small issue which failed on EPEL's
non-cooperation. I don't see why more important issues would ever have
a better faith, and I lost a lot of momentum in this fake
discussion. The bottom point is that EPEL just wanted to enter the
repo world of RHEL/CentOS
R P Herrold wrote:
On Wed, 5 Dec 2007, Rex Dieter wrote:
Huh? In fact, work is underway to codify the opposite:
http://fedoraproject.org/wiki/PackageMaintainers/RepositoryCollaboration
James 2:14-26
If you can identify particular cases where collaboration, as outlined in the
above
On Thu, 6 Dec 2007, Rex Dieter wrote:
R P Herrold wrote:
James 2:14-26
Rex Dieter replied:
If you can identify particular cases where collaboration, as
outlined in the above policy draft, was not followed, I will
personally break out a can of whoop-ass, and work to fix
things.
Remember
R P Herrold wrote:
Rex Dieter replied:
If you can identify particular cases where collaboration, as
outlined in the above policy draft, was not followed, I will
personally break out a can of whoop-ass, and work to fix
things.
Remember too, collaboration is a two-way street.
I never got
Rex Dieter wrote:
R P Herrold wrote:
On Wed, 5 Dec 2007, Rex Dieter wrote:
Huh? In fact, work is underway to codify the opposite:
http://fedoraproject.org/wiki/PackageMaintainers/RepositoryCollaboration
James 2:14-26
If you can identify particular cases where collaboration, as outlined
On Thu, 6 Dec 2007, Rex Dieter wrote:
that can't happen unless folks can out particular cases
where collaboration failed (esp on the epel side), so that I
can I can try to help.
'outed' in a off list email to Rex
In the meantime, I'll go digging on epel's list searching
for posts made by
On Dec 6, 2007 8:34 AM, R P Herrold [EMAIL PROTECTED] wrote:
On Thu, 6 Dec 2007, Rex Dieter wrote:
R P Herrold wrote:
James 2:14-26
Rex Dieter replied:
If you can identify particular cases where collaboration, as
outlined in the above policy draft, was not followed, I will
personally
[snip away bible quotes]
This is getting way off topic, please consider what you post.
//Morten
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos
Les Mikesell wrote:
I don't see why
a particular package couldn't be served from more than one repository.
Is there some rule about that?
Nope. As a matter of fact, this sort of thing is likely when mixing repos,
and is why a commitment to collaboration is essential.
-- Rex
Ray Van Dolson wrote:
It's unfortunate, but doesn't seem like it's going to change. I guess
that doesn't mean we need to stop talking about it, but maybe instead
of hollering about the need for repotags it's time to collaborate in
the other direction -- building a better way to track
On Thu, 6 Dec 2007, Stephen John Smoogen wrote:
Most of the bickering and infighting and keeping grudges about
things many years reminds me mostly of the Reformation. Protestants
killing Catholics, Catholics killing Protestants, Protestants
killing Protestants, Catholics killing Catholics,
On Dec 6, 2007 11:03 AM, Les Mikesell [EMAIL PROTECTED] wrote:
Morten Torstensen wrote:
[snip away bible quotes]
This is getting way off topic, please consider what you post.
Having only one true repository whose name shall not be uttered in the
package filenames doesn't remind you of
Rex Dieter wrote:
I don't see why
a particular package couldn't be served from more than one repository.
Is there some rule about that?
Nope. As a matter of fact, this sort of thing is likely when mixing repos,
and is why a commitment to collaboration is essential.
The point is that as an
Morten Torstensen wrote:
[snip away bible quotes]
This is getting way off topic, please consider what you post.
Having only one true repository whose name shall not be uttered in the
package filenames doesn't remind you of anything?
--
Les Mikesell
[EMAIL PROTECTED]
On Thu, Dec 06, 2007 at 12:03:51PM -0600, Les Mikesell wrote:
Morten Torstensen wrote:
[snip away bible quotes]
This is getting way off topic, please consider what you post.
Having only one true repository whose name shall not be uttered in the
package filenames doesn't remind you of
Paul Heinlein wrote:
Tom Lehrer sang it best:
http://www.youtube.com/watch?v=aIlJ8ZCs4jY
I was thinking more along the lines on Mick Jager:
http://www.youtube.com/watch?v=4FqGz0z4dI0
Dave Thompson
UW-Madison
___
CentOS mailing list
Stephen John Smoogen wrote:
The point is that as an end user, I want a sensible way to deal with
multiple repositories that _don't_ collaborate. After all, if everyone
agreed on policies we wouldn't need any third party repositories at all.
Ok the problem field is that you have N different
On Dec 6, 2007 2:24 PM, Axel Thimm [EMAIL PROTECTED] wrote:
So to answer the subject: No, EPEL is incompatible to every other repo
that existed before EPEL came up. That was not the original promise of
EPEL (I know as I was a steering member before I gave up on this
insanity course), but it
ok...
How about wxGTK.
rpmforge is distributing 2.6.3 while epel is distributing 2.8.?
rpmforge's vlc uses wxGTK or there are interlinked dependencies...
So when I yum -y update, the update fails. Currently there are no
pending updates so this is not a big deal... until there are pending
On Dec 6, 2007 4:53 PM, Karanbir Singh [EMAIL PROTECTED] wrote:
perhaps you didnt read the thread before posting, but I politely asked people
to
take it elsewhere.
Karanbir Singh : http://www.karan.org/ : [EMAIL PROTECTED]
If people ever listen to others, this thread would not have gone
Les Mikesell wrote:
Stephen John Smoogen wrote:
I would say that the only thing that needs to top this off is some
rumours that the other side is going to use bitkeeper for its source
control, or ESR saying they thought that ZYZ was now his preferred
repo and RMS saying that the other was the
Jim Perrin wrote:
On Dec 4, 2007 1:12 PM, Florin Andrei
[EMAIL PROTECTED] wrote:
Following Fabian's blog post re: RPMForge being rebuilt for EL5, I've a
question:
Are there any compatibility problems between RPMForge and EPEL? In other
words, if I enabled EPEL previously, will I be able to
29 matches
Mail list logo
