Les Mikesell wrote:

Radu-Cristian FOTESCU wrote:

...

OTOH, Dag is in a funny position: he's the main maintainer of RPMforge, which has 2 main issues: (1) It's broken, at least partially. Try install audacious for one. (2) It's incompatible with EPEL. Try install MPlayer and VLC with EPEL enabled.

I don't like this situation either, but when 2 repositories have conflicts, shouldn't the one that has been serving people longer have some consideration by the newer players? That is, shouldn't EPEL work to avoid conflicts with pre-existing, well known repositories?

It's a two-way street. When/if conflicts have occurred in the past, problems identified (to both parties) were rectified quick enough. I've helped facilitate that, and get assurances from both sides that cooperation is in everyones best interest.

-- Rex

Dag Wieers wrote:

Now, I always thought that RPMforge wouldn't have the resources to start making the repositories compatible, but apparently the Fedora projecy is simply not even interested in doing this.

Dag, we had a lengthy thread on the rpmforge list not long ago to debunk this, and I was under the impression you were ammendable to working together. Has something changed?

-- Rex

Dag Wieers wrote:

I don't see any effort from the Fedora side to do anything about this.

True, no one goes out of their way to proactively test things, but that same argument goes both ways.

What I'm more interested in is concrete examples of problems not being addressed. Are there any? I'd be happy to help address them.

-- Rex

not to be rude but back to the core of the original question:

is is safe to assume that future releases of Centos will remain a "built from publicly available open source SRPMS provided by a prominent North American Enterprise Linux vendor. CentOS conforms fully with the upstream vendors redistribution policies and aims to be 100% binary compatible. (CentOS mainly changes packages to remove upstream vendor branding and artwork).", AND all additional non-PNAELV packages will remain in the extra repository???

The whole point of the question is to make sure that Centos will remain 100% binary compatible with PNAELV, at least in terms of package version. This does not mean that others will not have the ability to break this 100% binary compatibility, at least in tersm of package version, by installing more "up-to-date" packages from "extra repositories".

By "extra repository(ies)" I mean any other repository that contains packages which are not in PNAELV.

thanks bn

On 06/29/2009 08:06 PM, Bogdan Nicolescu wrote:

The whole point of the question is to make sure that Centos will remain 100% binary compatible with PNAELV, at least in terms of package version. This does not mean that others will not have the ability to break this 100% binary compatibility, at least in tersm of package version, by installing more "up-to-date" packages from "extra repositories".

yes.

By "extra repository(ies)" I mean any other repository that contains packages which are not in PNAELV.

yes again, and some of these 'extra repos' might be hosted within the project itself.

- KB

While I don't want to just add noise to this thread, I think that there might be some miscommunication and/or misunderstanding involved here. I also want to express my appreciation to Dag and the folks who maintain the RPMforge repo, as I find it quite useful.

On Mon, 2009-06-29 at 20:34 +0200, Dag Wieers wrote:

On Mon, 29 Jun 2009, Radu-Cristian FOTESCU wrote:

...

...

A quick look at http://distrowatch.com/table.php?distribution=centos shows that a great majority of the packages are not even close to being "up-to-date", and that is a good thing for those us of who care more about stability than eyecandy.

That can't be other way. For instance, you can't build GIMP 2.4 or 2.6 unless you you upgrade to a newer GTK+, which would impact on a lot of apps.

The impression I get from the above exchange is that someone either has not read the CentOS mission statement, or does not understand it in the context of "enterprise" and "stable" distribution. This leads to dissatisfaction with their installations, since one of the costs of long-term stability is loss of the capability to upgrade package versions in a piecemeal manner.

...

OTOH, Dag is in a funny position: he's the main maintainer of RPMforge, which has 2 main issues: (1) It's broken, at least partially. Try install audacious for one. (2) It's incompatible with EPEL. Try install MPlayer and VLC with EPEL enabled.

These observations, while technically correct, show a lack of familiarity with the long-running differences of opinion between the RPMforge folks and the EPEL crew. Again, in the technical/factual universe, I support Dag's response below, but in the political/emotional world, I hope that this is not indicating a bump up against the limits of his patience with these conflicting viewpoints.

(1) I expect now patches from you to make a workable audacious based on our audacious package. Apparently you have the interest and the time to do it ?

(2) No, they are not compatible, we know. Share to help with this too ? You first have to convince the Fedora people that they will not introduce new incompatibilities before starting. I'd right merge, but also that is not happening as there is no interest. So what is the solution ? Shall I simply stop doing RPMforge ?

Here I will speak for myself, while hoping that there are others who will agree:

HELL NO !!!

I'm not enough of a programmer to even THINK of replacing the talent you bring to the table, and I suspect that there are relatively few people who DO posses those skills who would also have the dedication you do. I will say it if nobody else will: The distros supported by RPMforge would be poorer without your efforts.

Is that the position you prefer to force me into ? Because I certainly did not force you into using the repository.

On the lighter side: If you HAD forced anyone to use the repository, I suspect that you would have forced them to read the relevant docs ( HOWTOs, etc. ) FIRST. ;>

I don't know even why you want to use RPMforge, there must be something that is missing from EPEL ?

I am happy to learn what you want to do though, because it is easy to criticize, but it takes time to do some work.

(And I hope the solution is not another repository, because we have been there :-))

Dag Wieers wrote:

On Mon, 29 Jun 2009, Radu-Cristian FOTESCU wrote:

...

...

A quick look at http://distrowatch.com/table.php?distribution=centos shows that a great majority of the packages are not even close to being "up-to-date", and that is a good thing for those us of who care more about stability than eyecandy.

That can't be other way. For instance, you can't build GIMP 2.4 or 2.6 unless you you upgrade to a newer GTK+, which would impact on a lot of apps.

OTOH, Dag is in a funny position: he's the main maintainer of RPMforge, which has 2 main issues: (1) It's broken, at least partially. Try install audacious for one. (2) It's incompatible with EPEL. Try install MPlayer and VLC with EPEL enabled.

(1) I expect now patches from you to make a workable audacious based on our audacious package. Apparently you have the interest and the time to do it ?

(2) No, they are not compatible, we know. Share to help with this too ? You first have to convince the Fedora people that they will not introduce new incompatibilities before starting. I'd right merge, but also that is not happening as there is no interest. So what is the solution ? Shall I simply stop doing RPMforge ?

Is that the position you prefer to force me into ? Because I certainly did not force you into using the repository.

I don't know even why you want to use RPMforge, there must be something that is missing from EPEL ?

I am happy to learn what you want to do though, because it is easy to criticize, but it takes time to do some work.

(And I hope the solution is not another repository, because we have been there :-))

Et Al Let me try to put into words my appreciation for ALL those that contribute to Linux and in particular CentOS and supporting repos. I am a long time linux user, only mildly computer literate and a small business owner / operator now living and working in the USA (once London and New Zealand). The considerable work to rebuild the Red Hat originated SRPMs and then the various other RPMs that make this a truly useful desktop / workstation / laptop distro is acknowledged and appreciated. I have had an initial look at trying to offer some help in the build process but so far am too lost to be of much help. I try to contribute where possible, particularly on the CentOS forum and mailing list. Now to the apparent issues with RPMforge / EPEL. At this time I use both, but due to the time I started with these RPMforge is priority=22 with EPEL behind that at priority=34 and normally enabled=0 If I was starting again this may change - ?? Due to the complexity of the RPM build process, differing priorities, methods of working and perspective I am sure there will always be incompatibilities. I for one would please ask that you please work together as much as you can, don't take the words used and expressed via email and forums too literally. Most of us do not have the skills to express what we really mean and sometimes our communication may come across as criticism but this is certainly not our intent as we REALLY DO APPRECIATE all that you each do to make our favorite linux work so well. Many thanks for your continued support and resources. Rob

Hi all,

I have been using RPMforge much longer than EPEL and only have a few packages from EPEL on my 5.3 (32 bit) desktop. When I added the EPEL Repository to Priorities, the number of packages excluded went from approximately 400 to 1705. My belief is that had I not given EPEL a very low priority, it would have replaced approximately 1300 packages. Probably those whose priority is to have the latest and greatest should be using another distro (Fedora, Ubuntu, etc.). The philosophy behind Enterprise Distros is stability and security and long life, not having the latest and greatest packages.

There was a time where CentOS contrib repo has been announced. It was meant to be a package source for 'community-contributed' packages. So why not just merge stable RPMForge packages over there and start a 'semi-official' CentOS orientated repository from the scratch.

Best Regars Marcus

Ned Slider napsal(a):

Rather than dumping *even more work* on the core CentOS project (who are already clearly struggling to provide even the core distro at present), why doesn't everyone do as Dag suggested, and adopt a handful of packages and help maintain them at rpmforge for the benefit of everyone.

If everyone who has offered help in this thread, or commented that they maintain their own repos, offered to maintain a handful of packages at rpmforge then it all adds up.

Ned, I have written it a few hours before. RPMforge is fine. But every day work require something more which rpmforge is not able to provide within its current state. That's why I have been pointing out the rpmrepo. David

R P Herrold wrote:

On Tue, 30 Jun 2009, Ned Slider wrote:

...

Rather than dumping *even more work* on the core CentOS project (who are already clearly struggling to provide even the core distro at present), ...

It may be clear to Ned, but is not the case.

Then we disagree. Others can look and judge for themselves :)

I wish people not in the know would not purport to characterize CentOS internals, but speculation is a human trait, I guess

Bingo! That's the whole point Russ - members of the Community don't know what's going on with *their* Community Enterprise OS because there is no dissemination of information.

What I *do* "know" is that 5.3 took ~10 weeks to release, and before that 4.7 took ~7 weeks. We are already 6 weeks into the 4.8 release cycle with no news of how it's progressing or when a release is to be expected. Prior to this, update sets typically took ~4 weeks to release.

Struggling? Maybe/maybe not. Struggling within a reasonable time frame - depends on your definition of reasonable and time frame I guess. Perhaps this is where we disagree above.

Anyway, as I said previously, I would rather see the CentOS Project concentrate on the core product and do a really good job on that (i.e, a move closer to the old 4 week release lag than the current 10 week release lag), and I would much rather see this than effort diluted by taking on a contrib repo.

I would note that from the earliest days of RPMForge, Dag offered, and indeed granted comit rights to me, which I have not used. I find it easier to use the bug tracker, and to send emails to him ... lazy of me, I know, but again human nature in play

Additionally I regularly pull, fork, and fix 'broken' RF packages [for self, or in consulting engagements], and drop the SRPM's in my personal archive to satisfy GPL source availability obligations. I've seem parts of my packagings end up elsewhere which is fine

On Wed, 2009-07-01 at 00:10 +0100, Ned Slider wrote:

R P Herrold wrote:

...

On Tue, 30 Jun 2009, Ned Slider wrote:

...

Rather than dumping *even more work* on the core CentOS project (who are already clearly struggling to provide even the core distro at present), ...

It may be clear to Ned, but is not the case.

Then we disagree. Others can look and judge for themselves :)

+1

...

I wish people not in the know would not purport to characterize CentOS internals, but speculation is a human trait, I guess

Bingo! That's the whole point Russ - members of the Community don't know what's going on with *their* Community Enterprise OS because there is no dissemination of information.

+1

What I *do* "know" is that 5.3 took ~10 weeks to release, and before that 4.7 took ~7 weeks. We are already 6 weeks into the 4.8 release cycle with no news of how it's progressing or when a release is to be expected. Prior to this, update sets typically took ~4 weeks to release.

+1

Struggling? Maybe/maybe not. Struggling within a reasonable time frame - depends on your definition of reasonable and time frame I guess. Perhaps this is where we disagree above.

Anyway, as I said previously, I would rather see the CentOS Project concentrate on the core product and do a really good job on that (i.e, a move closer to the old 4 week release lag than the current 10 week release lag), and I would much rather see this than effort diluted by taking on a contrib repo.

+1

Steve

Rather than dumping *even more work* on the core CentOS project (who are already clearly struggling to provide even the core distro at present), why doesn't everyone do as Dag suggested, and adopt a handful of packages and help maintain them at rpmforge for the benefit of everyone.

If everyone who has offered help in this thread, or commented that they maintain their own repos, offered to maintain a handful of packages at rpmforge then it all adds up.

good idea.

Dag Wieers napsal(a):

I am all for a solution, but unless it already works I would not call it a solution, but a short-term (and possibly long-term) risk.

I hasn't been working and I dare to say not because the community... So I don't see any way how can contrib work after those years. :o( David