Hi
I'm trying to install amavisd-new from dag repo on centos3. In the spec file perl dependencies use parenthesis: perl(Digest::MD5) it also uses '-': perl-MailTools
The problem is that only the second notation is available: perl-MD5
I know this is an old problem. Is this only centos related? Is there a workaround?
Do I have to modify the spec file? I'd like to use yum...
Regards
On 4/20/06, sophana sophana@zizi.ath.cx wrote:
Hi
I'm trying to install amavisd-new from dag repo on centos3. In the spec file perl dependencies use parenthesis: perl(Digest::MD5) it also uses '-': perl-MailTools
The problem is that only the second notation is available: perl-MD5
I know this is an old problem. Is this only centos related? Is there a workaround?
Do I have to modify the spec file? I'd like to use yum...
I use amavisd-new as well.
I ran into some Per modules missing when using Dag. I switched to using RPMForge, which is a merger of Dag, Dries, and maybe one or two more. Since then I have not had the problem.
YMMV
-- Leonard Isham, CISSP Ostendo non ostento.
On Fri, 2006-04-21 at 15:15 -0400, Leonard Isham wrote:
On 4/20/06, sophana sophana@zizi.ath.cx wrote:
<snip>
I ran into some Per modules missing when using Dag. I switched to using RPMForge, which is a merger of Dag, Dries, and maybe one or two more. Since then I have not had the problem.
Plus Dag habitually recommends RPMForge for "normal" stuff now. So unless you know of a special situation, try RPMForge first.
YMMV
<snip sig stuff>
On Fri, 21 Apr 2006, Leonard Isham wrote:
On 4/20/06, sophana sophana@zizi.ath.cx wrote:
Hi
I'm trying to install amavisd-new from dag repo on centos3. In the spec file perl dependencies use parenthesis: perl(Digest::MD5) it also uses '-': perl-MailTools
The problem is that only the second notation is available: perl-MD5
I know this is an old problem. Is this only centos related? Is there a workaround?
Do I have to modify the spec file? I'd like to use yum...
I use amavisd-new as well.
I ran into some Per modules missing when using Dag. I switched to using RPMForge, which is a merger of Dag, Dries, and maybe one or two more. Since then I have not had the problem.
Next time, do us all a favor and report if something is not working.
Kind regards, -- dag wieers, dag@wieers.com, http://dag.wieers.com/ -- [all I want is a warm bed and a kind word and unlimited power]
What I don't understand, is that it works with centos 4 Is my rpm database broken? I have an old centos 3.3, and cannot update because of broken dependencies.
Dag Wieers wrote:
Next time, do us all a favor and report if something is not working.
On 4/23/06, sophana sophana@zizi.ath.cx wrote:
What I don't understand, is that it works with centos 4.
Centos 4 has a totally different package set, and a newer version of yum.
Is my rpm database broken?
I have no clue. You haven't given us enough information to know at this point.
I have an old centos 3.3, and cannot update because of broken dependencies.
3.3 is REALLY old (3.7 is the current version of centos3) and outdated. I'd recommend removing whatever the dependency is on your system, updating, and then re-installing the app. This advice may not apply if you've done something destructive to your system, or if you're expecting rpm to pick up things you've built from source. With the information you've given us, there isn't much to go on for answers at this point.
-- This message has been double ROT13 encoded for security. Anyone other than the intended recipient attempting to decode this message will be in violation of the DMCA
did some investigations # yum install amavisd-new Gathering header information file(s) from server(s) Server: CentOS-3.3 - Addons Server: ATrpms for rhel 3 stable Server: ATrpms for rhel 3 testing Server: CentOS-3.3 - Base Server: CentOS-3.3 - Extras Server: Dag RPM Repository for Red Hat Enterprise Linux Server: dries el3 repo Server: CentOS-3.3 - Extras Server: kde-redhat.org (kde-stable) Server: kde-redhat.org (kde-stable-all) Server: CentOS-3.3 - Updates Finding updated packages Downloading needed headers Resolving dependencies ......Unable to satisfy dependencies Package amavisd-new needs perl(Digest::MD5) >= 2.22, this is not available. Package amavisd-new needs perl(Time::HiRes) >= 1.49, this is not available.
perl-Time-HiRes is version 1.38 in the centos 3 repo. So this is normal it doesn't work.
however I don't understand this bug: # yum install rpm Gathering header information file(s) from server(s) Server: CentOS-3.3 - Addons Server: ATrpms for rhel 3 stable Server: ATrpms for rhel 3 testing Server: CentOS-3.3 - Base Server: CentOS-3.3 - Extras Server: Dag RPM Repository for Red Hat Enterprise Linux Server: dries el3 repo Server: CentOS-3.3 - Extras Server: kde-redhat.org (kde-stable) Server: kde-redhat.org (kde-stable-all) Server: CentOS-3.3 - Updates Finding updated packages Downloading needed headers Resolving dependencies .......Unable to satisfy dependencies Package rpm-libs needs rpm = 4.2.3-24_nonptl, this is not available. # rpm -q rpm rpm-4.2.3-10 # ls /var/cache/yum/base/headers/rpm-libs* /var/cache/yum/base/headers/rpm-libs-0-4.2.3-21_nonptl.i386.hdr /var/cache/yum/base/headers/rpm-libs-0-4.2.3-24_nonptl.i386.hdr
I noticed lots of bugs in yum. This is really annoying.
Jim Perrin wrote:
On 4/23/06, sophana sophana@zizi.ath.cx wrote:
What I don't understand, is that it works with centos 4.
Centos 4 has a totally different package set, and a newer version of yum.
Is my rpm database broken?
I have no clue. You haven't given us enough information to know at this point.
I have an old centos 3.3, and cannot update because of broken dependencies.
3.3 is REALLY old (3.7 is the current version of centos3) and outdated. I'd recommend removing whatever the dependency is on your system, updating, and then re-installing the app. This advice may not apply if you've done something destructive to your system, or if you're expecting rpm to pick up things you've built from source. With the information you've given us, there isn't much to go on for answers at this point.
-- This message has been double ROT13 encoded for security. Anyone other than the intended recipient attempting to decode this message will be in violation of the DMCA _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
On Sun, 2006-04-23 at 23:19 +0200, sophana wrote:
did some investigations # yum install amavisd-new Gathering header information file(s) from server(s) Server: CentOS-3.3 - Addons Server: ATrpms for rhel 3 stable Server: ATrpms for rhel 3 testing Server: CentOS-3.3 - Base Server: CentOS-3.3 - Extras Server: Dag RPM Repository for Red Hat Enterprise Linux Server: dries el3 repo Server: CentOS-3.3 - Extras Server: kde-redhat.org (kde-stable) Server: kde-redhat.org (kde-stable-all) Server: CentOS-3.3 - Updates Finding updated packages Downloading needed headers Resolving dependencies ......Unable to satisfy dependencies Package amavisd-new needs perl(Digest::MD5) >= 2.22, this is not available. Package amavisd-new needs perl(Time::HiRes) >= 1.49, this is not available.
perl-Time-HiRes is version 1.38 in the centos 3 repo. So this is normal it doesn't work.
however I don't understand this bug: # yum install rpm Gathering header information file(s) from server(s) Server: CentOS-3.3 - Addons Server: ATrpms for rhel 3 stable Server: ATrpms for rhel 3 testing Server: CentOS-3.3 - Base Server: CentOS-3.3 - Extras Server: Dag RPM Repository for Red Hat Enterprise Linux Server: dries el3 repo Server: CentOS-3.3 - Extras Server: kde-redhat.org (kde-stable) Server: kde-redhat.org (kde-stable-all) Server: CentOS-3.3 - Updates Finding updated packages Downloading needed headers Resolving dependencies .......Unable to satisfy dependencies Package rpm-libs needs rpm = 4.2.3-24_nonptl, this is not available. # rpm -q rpm rpm-4.2.3-10 # ls /var/cache/yum/base/headers/rpm-libs* /var/cache/yum/base/headers/rpm-libs-0-4.2.3-21_nonptl.i386.hdr /var/cache/yum/base/headers/rpm-libs-0-4.2.3-24_nonptl.i386.hdr
I noticed lots of bugs in yum. This is really annoying.
There is not a bug in yum (well, not in this case ... I'm sure yum has some bugs) ... the problem is that the repositories that you have chosen have conflicting packages, or you are not pointed to the proper CentOS repos.
Please understand that adding 3rd party repositories and performing an update will replace core packages in CentOS.
Also, with the proper version of CentOS release installed, it will say:
CentOS-3 Base (and Addons, Extras, etc.) ... not CentOS-3.3
So ... somehow it seems that you do not have the proper centos-release installed, and that you are not getting the proper updates.
Your yum.conf file for CentOS-3 should look like this for the CentOS portion if that file: ----------------- [base] name=CentOS-$releasever - Base baseurl=http://mirror.centos.org/centos/$releasever/os/$basearch/ gpgcheck=1
#released updates [update] name=CentOS-$releasever - Updates baseurl=http://mirror.centos.org/centos/$releasever/updates/$basearch/ gpgcheck=1
#packages used/produced in the build but not released [addons] name=CentOS-$releasever - Addons baseurl=http://mirror.centos.org/centos/$releasever/addons/$basearch/ gpgcheck=1
#additional packages that may be useful [extras] name=CentOS-$releasever - Extras baseurl=http://mirror.centos.org/centos/$releasever/extras/$basearch/ gpgcheck=1 -------------------------------- AND ... you should have this centos-release file:
centos-release-3-7.1
I'm not sure exactly what you have in your yum.conf ... but I just installed from a 3.3 CD and updated to 3.7 with no problems at all as a test.
Jim Perrin wrote:
On 4/23/06, sophana sophana@zizi.ath.cx wrote:
What I don't understand, is that it works with centos 4.
Centos 4 has a totally different package set, and a newer version of yum.
Is my rpm database broken?
I have no clue. You haven't given us enough information to know at this point.
I have an old centos 3.3, and cannot update because of broken dependencies.
3.3 is REALLY old (3.7 is the current version of centos3) and outdated. I'd recommend removing whatever the dependency is on your system, updating, and then re-installing the app. This advice may not apply if you've done something destructive to your system, or if you're expecting rpm to pick up things you've built from source. With the information you've given us, there isn't much to go on for answers at this point.
-- This message has been double ROT13 encoded for security. Anyone other than the intended recipient attempting to decode this message will be in violation of the DMCA _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
On Sun, 23 Apr 2006, Johnny Hughes wrote:
On Sun, 2006-04-23 at 23:19 +0200, sophana wrote:
did some investigations # yum install amavisd-new Gathering header information file(s) from server(s) Server: CentOS-3.3 - Addons Server: ATrpms for rhel 3 stable Server: ATrpms for rhel 3 testing Server: CentOS-3.3 - Base Server: CentOS-3.3 - Extras Server: Dag RPM Repository for Red Hat Enterprise Linux Server: dries el3 repo Server: CentOS-3.3 - Extras Server: kde-redhat.org (kde-stable) Server: kde-redhat.org (kde-stable-all) Server: CentOS-3.3 - Updates Finding updated packages Downloading needed headers Resolving dependencies ......Unable to satisfy dependencies Package amavisd-new needs perl(Digest::MD5) >= 2.22, this is not available. Package amavisd-new needs perl(Time::HiRes) >= 1.49, this is not available.
perl-Time-HiRes is version 1.38 in the centos 3 repo. So this is normal it doesn't work.
however I don't understand this bug: # yum install rpm Gathering header information file(s) from server(s) Server: CentOS-3.3 - Addons Server: ATrpms for rhel 3 stable Server: ATrpms for rhel 3 testing Server: CentOS-3.3 - Base Server: CentOS-3.3 - Extras Server: Dag RPM Repository for Red Hat Enterprise Linux Server: dries el3 repo Server: CentOS-3.3 - Extras Server: kde-redhat.org (kde-stable) Server: kde-redhat.org (kde-stable-all) Server: CentOS-3.3 - Updates Finding updated packages Downloading needed headers Resolving dependencies .......Unable to satisfy dependencies Package rpm-libs needs rpm = 4.2.3-24_nonptl, this is not available. # rpm -q rpm rpm-4.2.3-10 # ls /var/cache/yum/base/headers/rpm-libs* /var/cache/yum/base/headers/rpm-libs-0-4.2.3-21_nonptl.i386.hdr /var/cache/yum/base/headers/rpm-libs-0-4.2.3-24_nonptl.i386.hdr
I noticed lots of bugs in yum. This is really annoying.
There is not a bug in yum (well, not in this case ... I'm sure yum has some bugs) ... the problem is that the repositories that you have chosen have conflicting packages, or you are not pointed to the proper CentOS repos.
This is a bug in Yum. Yum only considers the latest version of amavisd-new and that one has unresolved dependencies.
I have a problem here. I try so hard not to replace core packages, but amavisd-new needs a newer perl module that is a core package.
Either people complain that I replace core packages, or they complain that I do not have amavisd-new 3.4 and if I provide both, Yum would complain anyway because it is stupid. That's why I always suggest to use either apt or smart as they are much smarter in resolving problems and providing you with a working set of packages.
Please understand that adding 3rd party repositories and performing an update will replace core packages in CentOS.
Yes, and what would you expect, I can not provide a recent amavisd-new without replacing core packages. And if I don't people complain as well. To be honest I'm getting tired of this :(
Kind regards, -- dag wieers, dag@wieers.com, http://dag.wieers.com/ -- [all I want is a warm bed and a kind word and unlimited power]
Dag Wieers wrote:
There is not a bug in yum (well, not in this case ... I'm sure yum has some bugs) ... the problem is that the repositories that you have chosen have conflicting packages, or you are not pointed to the proper CentOS repos.
This is a bug in Yum. Yum only considers the latest version of amavisd-new and that one has unresolved dependencies.
I have a problem here. I try so hard not to replace core packages, but amavisd-new needs a newer perl module that is a core package.
Either people complain that I replace core packages, or they complain that I do not have amavisd-new 3.4 and if I provide both, Yum would complain anyway because it is stupid.
The problem is that you have to replace *perl* to meet the dependency on Digest::MD5 amavisd-new is having. Because of the shitty @INC ordering in RHEL (*and* perl itself) you cannot even push a new Digest::MD5 to vendor_perl/ or site_perl/ as that is not going to be picked up:
| @INC: | /usr/lib/perl5/5.8.0/i386-linux-thread-multi | /usr/lib/perl5/5.8.0 | /usr/lib/perl5/site_perl/5.8.0/i386-linux-thread-multi | /usr/lib/perl5/site_perl/5.8.0 | /usr/lib/perl5/site_perl | /usr/lib/perl5/vendor_perl/5.8.0/i386-linux-thread-multi | /usr/lib/perl5/vendor_perl/5.8.0 | /usr/lib/perl5/vendor_perl
There's a bugzilla entry concerning that (which I cannot find anymore at the moment), but it didn't look like RH wanted to change that.
So I don't think that this is a yum bug, this is a bug in RedHat's perl packaging, as you are not able to override modules which are included with the core perl package. And that hasn't change up to FC5.
Ralph
On Mon, 24 Apr 2006, Ralph Angenendt wrote:
Dag Wieers wrote:
There is not a bug in yum (well, not in this case ... I'm sure yum has some bugs) ... the problem is that the repositories that you have chosen have conflicting packages, or you are not pointed to the proper CentOS repos.
This is a bug in Yum. Yum only considers the latest version of amavisd-new and that one has unresolved dependencies.
I have a problem here. I try so hard not to replace core packages, but amavisd-new needs a newer perl module that is a core package.
Either people complain that I replace core packages, or they complain that I do not have amavisd-new 3.4 and if I provide both, Yum would complain anyway because it is stupid.
The problem is that you have to replace *perl* to meet the dependency on Digest::MD5 amavisd-new is having. Because of the shitty @INC ordering in RHEL (*and* perl itself) you cannot even push a new Digest::MD5 to vendor_perl/ or site_perl/ as that is not going to be picked up:
| @INC: | /usr/lib/perl5/5.8.0/i386-linux-thread-multi | /usr/lib/perl5/5.8.0 | /usr/lib/perl5/site_perl/5.8.0/i386-linux-thread-multi | /usr/lib/perl5/site_perl/5.8.0 | /usr/lib/perl5/site_perl | /usr/lib/perl5/vendor_perl/5.8.0/i386-linux-thread-multi | /usr/lib/perl5/vendor_perl/5.8.0 | /usr/lib/perl5/vendor_perl
There's a bugzilla entry concerning that (which I cannot find anymore at the moment), but it didn't look like RH wanted to change that.
Correct, I would have to replace perl. That's why I don't :)
So I don't think that this is a yum bug, this is a bug in RedHat's perl packaging, as you are not able to override modules which are included with the core perl package. And that hasn't change up to FC5.
It's a bug in Yum that it does not consider the previous amavisd-new. Apt and smart would do that. This allows me to provide a newer amavisd-new for those people that do provide a newer perl-Digest-MD5 (there are multiple ways you can fix the dependencies and run amavisd-new).
But Yum truly fails to work now, or I have to stop offer the latest amavisd-new. This is a flaw in Yum in my opinion, and a flaw in the repository in Seth's opinion.
And that's why am I now practically forced to follow the lowest common denominator, which is Yum.
Sorry if I didn't make that obvious in my previous mail.
Kind regards, -- dag wieers, dag@wieers.com, http://dag.wieers.com/ -- [all I want is a warm bed and a kind word and unlimited power]
On Mon, 2006-04-24 at 05:39, Dag Wieers wrote:
There's a bugzilla entry concerning that (which I cannot find anymore at the moment), but it didn't look like RH wanted to change that.
Correct, I would have to replace perl. That's why I don't :)
I thought perl could be perfectly happy with multiple versions living on the same machine as long as you keep your paths straight. There should be no need to replace the existing one to install something newer.
So I don't think that this is a yum bug, this is a bug in RedHat's perl packaging, as you are not able to override modules which are included with the core perl package. And that hasn't change up to FC5.
It's a bug in Yum that it does not consider the previous amavisd-new. Apt and smart would do that. This allows me to provide a newer amavisd-new for those people that do provide a newer perl-Digest-MD5 (there are multiple ways you can fix the dependencies and run amavisd-new).
It is an unrealistic expectation in both RPM and yum that you won't ever need to run multiple versions of some programs on the same machine at the same time. Is this the first time you've seen this problem? Pretty much every developer that needs a stable version working while he tests the next one should have run into it.
On Mon, 24 Apr 2006, Les Mikesell wrote:
On Mon, 2006-04-24 at 05:39, Dag Wieers wrote:
There's a bugzilla entry concerning that (which I cannot find anymore at the moment), but it didn't look like RH wanted to change that.
Correct, I would have to replace perl. That's why I don't :)
I thought perl could be perfectly happy with multiple versions living on the same machine as long as you keep your paths straight. There should be no need to replace the existing one to install something newer.
Sure, I can make a package that adds the same version (or a newer version) of perl available alongside the current one. Would it be advisable ? No.
So I don't think that this is a yum bug, this is a bug in RedHat's perl packaging, as you are not able to override modules which are included with the core perl package. And that hasn't change up to FC5.
It's a bug in Yum that it does not consider the previous amavisd-new. Apt and smart would do that. This allows me to provide a newer amavisd-new for those people that do provide a newer perl-Digest-MD5 (there are multiple ways you can fix the dependencies and run amavisd-new).
It is an unrealistic expectation in both RPM and yum that you won't ever need to run multiple versions of some programs on the same machine at the same time. Is this the first time you've seen this problem? Pretty much every developer that needs a stable version working while he tests the next one should have run into it.
I guess I wasn't clear the second time in explaining what the problem is. So here I will add another example:
User wants to install amavisd-new. Repository has amavisd-new 2.3.3 and 2.4.0. Package amavisd-new 2.4.0 has a missing dependency (unless you replace a core package)
Yum will fail to work as it will only consider version 2.4.0 in resolving dependencies. Apt and smart will correctly install the latest package.
According to the Yum developers this situation is a repository problem. But I disagree, I should be able to provide packages (like version 2.4.0) to people that are able to fix the dependencies manually without blocking _all_ other users.
There are other advantages to provide newer packages that are uninstallable (by default) as people then tend to understand that the problem is related to upstream (either Red Hat or amavisd-new developers).
Also, other repositories might wish to choose to offer a perl replacement package, unlocking the situation for amavisd-new 2.4.0. So the argument that the repository has a problem is a fallacy and is only true if you consider a repository to be self-consistent. And the _only_ self-consistent repository there is, is the original OS repository.
Now, regarding your statement about installing 2 programs alongside each other. Often programs don't even work if they are installed together and there is little need for normal users to have multiple versions (except in certain cases). Besides, developers seldom use RPMs for simply testing their applications.
Besides that, RPM does allow different versions to be installed at the same time, using the same rules as allowing 2 different editors to be installed at the same time. It's just a discussion about semantics.
Kind regards, -- dag wieers, dag@wieers.com, http://dag.wieers.com/ -- [all I want is a warm bed and a kind word and unlimited power]
On Tue, 2006-04-25 at 13:26 +0200, Dag Wieers wrote:
On Mon, 24 Apr 2006, Les Mikesell wrote:
On Mon, 2006-04-24 at 05:39, Dag Wieers wrote:
There's a bugzilla entry concerning that (which I cannot find anymore at the moment), but it didn't look like RH wanted to change that.
Correct, I would have to replace perl. That's why I don't :)
I thought perl could be perfectly happy with multiple versions living on the same machine as long as you keep your paths straight. There should be no need to replace the existing one to install something newer.
Sure, I can make a package that adds the same version (or a newer version) of perl available alongside the current one. Would it be advisable ? No.
So I don't think that this is a yum bug, this is a bug in RedHat's perl packaging, as you are not able to override modules which are included with the core perl package. And that hasn't change up to FC5.
It's a bug in Yum that it does not consider the previous amavisd-new. Apt and smart would do that. This allows me to provide a newer amavisd-new for those people that do provide a newer perl-Digest-MD5 (there are multiple ways you can fix the dependencies and run amavisd-new).
It is an unrealistic expectation in both RPM and yum that you won't ever need to run multiple versions of some programs on the same machine at the same time. Is this the first time you've seen this problem? Pretty much every developer that needs a stable version working while he tests the next one should have run into it.
I guess I wasn't clear the second time in explaining what the problem is. So here I will add another example:
User wants to install amavisd-new. Repository has amavisd-new 2.3.3 and 2.4.0. Package amavisd-new 2.4.0 has a missing dependency (unless you replace a core package)
Nothing is stopping them from having the error, understanding the issue and doing this in their yum.conf:
exclude=amavisd-new-2.4.0
Then ... yum should resolve the depenancies
Yum will fail to work as it will only consider version 2.4.0 in resolving dependencies. Apt and smart will correctly install the latest package.
Actually ... Apt and smart are smart enough to install the older package .... which is maybe good, and maybe not.
I would think that if I see no errors that I have the latest packages ... which I don't (I have amavisd-new-2.3.3 and not 2.4.0 ... so I don't even know there is a problem unless I happen to see it is not the version that I think it should be).
According to the Yum developers this situation is a repository problem. But I disagree, I should be able to provide packages (like version 2.4.0) to people that are able to fix the dependencies manually without blocking _all_ other users.
If they exclude the new package because they can't solve the dependencies, then they can upgrade ... and they know they have a problem.
People who want the older packages to automatically install can use either apt or smartpm ... if they really want to.
BTW ... this is not really a repo problem or a yum problem ... it is the supplier of the software who choose to not support RHEL. They really should support RHEL with their products if they want it used in the business world. That is my opinion, but I could be wrong :)
There are other advantages to provide newer packages that are uninstallable (by default) as people then tend to understand that the problem is related to upstream (either Red Hat or amavisd-new developers).
Also, other repositories might wish to choose to offer a perl replacement package, unlocking the situation for amavisd-new 2.4.0. So the argument that the repository has a problem is a fallacy and is only true if you consider a repository to be self-consistent. And the _only_ self-consistent repository there is, is the original OS repository.
That is true. Other people might offer another upgrade ... at which time you can remove that package from your exclude.
All the good yum stuff I talked about works w/ version 2.4.x ... version 2.0.x is not so fully featured. We are looking into using a yum 2.4.x w/centos3 as well, if it is possible (python version issues need to be worked out for that).
Now, regarding your statement about installing 2 programs alongside each other. Often programs don't even work if they are installed together and there is little need for normal users to have multiple versions (except in certain cases). Besides, developers seldom use RPMs for simply testing their applications.
Besides that, RPM does allow different versions to be installed at the same time, using the same rules as allowing 2 different editors to be installed at the same time. It's just a discussion about semantics.
Dag, you know that CentOS appreciates all that you do, and the 3rd party repo thing is not at all meant to insinuate that your repo is anything other than top notch ... I use it on every single computer that I admin :)
I also would not recommend that someone add the CentOSPlus repo or the CentOS-Testing repo and run "yum update" without using includepkgs="the_stuff_they_want" either ... as it will update core packages and can cause issues too.
Thanks, Johnny Hughes
On Tue, 2006-04-25 at 15:51, Johnny Hughes wrote:
All the good yum stuff I talked about works w/ version 2.4.x ... version 2.0.x is not so fully featured. We are looking into using a yum 2.4.x w/centos3 as well, if it is possible (python version issues need to be worked out for that).
Please don't break the ability in Centos3 to 'yum --download-only update' followed by a later 'yum update' to be able to more accurately schedule the time an update and possible reboot will be completed. That feature seems to have disappeared in the newer versions.
On Tue, 2006-04-25 at 17:00 -0500, Les Mikesell wrote:
On Tue, 2006-04-25 at 15:51, Johnny Hughes wrote:
All the good yum stuff I talked about works w/ version 2.4.x ... version 2.0.x is not so fully featured. We are looking into using a yum 2.4.x w/centos3 as well, if it is possible (python version issues need to be worked out for that).
Please don't break the ability in Centos3 to 'yum --download-only update' followed by a later 'yum update' to be able to more accurately schedule the time an update and possible reboot will be completed. That feature seems to have disappeared in the newer versions.
There is a yum-plugin called "yumdownloader" ... it is part up yum- utils.
Take a look, I think you will like it.
On Tue, 2006-04-25 at 17:09 -0500, Johnny Hughes wrote:
On Tue, 2006-04-25 at 17:00 -0500, Les Mikesell wrote:
On Tue, 2006-04-25 at 15:51, Johnny Hughes wrote:
All the good yum stuff I talked about works w/ version 2.4.x ... version 2.0.x is not so fully featured. We are looking into using a yum 2.4.x w/centos3 as well, if it is possible (python version issues need to be worked out for that).
Please don't break the ability in Centos3 to 'yum --download-only update' followed by a later 'yum update' to be able to more accurately schedule the time an update and possible reboot will be completed. That feature seems to have disappeared in the newer versions.
There is a yum-plugin called "yumdownloader" ... it is part up yum- utils.
Take a look, I think you will like it.
it is a utility and not a plugin ... sorry ... here is how you can do it:
1. Edit /etc/yum.conf and set debuglevel=0
2. Make sure you have yum-utils
yum install yum-utils
3. see if you have any updates:
yum check-update
4. if you have updates, to download only:
yumdownloader `yum check-update | awk {'print $1'}`
Thanks, Johnny Hughes
On Tue, 2006-04-25 at 17:26, Johnny Hughes wrote:
All the good yum stuff I talked about works w/ version 2.4.x ... version 2.0.x is not so fully featured. We are looking into using a yum 2.4.x w/centos3 as well, if it is possible (python version issues need to be worked out for that).
Please don't break the ability in Centos3 to 'yum --download-only update' followed by a later 'yum update' to be able to more accurately schedule the time an update and possible reboot will be completed. That feature seems to have disappeared in the newer versions.
There is a yum-plugin called "yumdownloader" ... it is part up yum- utils.
Take a look, I think you will like it.
it is a utility and not a plugin ... sorry ... here is how you can do it:
Edit /etc/yum.conf and set debuglevel=0
Make sure you have yum-utils
yum install yum-utils
- see if you have any updates:
yum check-update
- if you have updates, to download only:
yumdownloader `yum check-update | awk {'print $1'}`
Thanks - after seeing your other message I was just about to point out that you have to tell it what to download and the whole point of using yum is that you don't have to know ahead of time... Seems odd that it doesn't have a shorthand notation to do that by itself, though.
On Tue, 25 Apr 2006, Les Mikesell wrote:
On Tue, 2006-04-25 at 17:26, Johnny Hughes wrote:
We are looking into using a yum 2.4.x w/centos3 if possible
Please don't break the ability in Centos3 to 'yum --download-only update' followed by a later 'yum update' to be able to more accurately schedule the time an update and possible reboot will be completed. That feature seems to have disappeared in the newer versions.
There is a yum-plugin called "yumdownloader" ... it is part up yum- utils.
it is a utility and not a plugin ... sorry ... here is how you can do it:
- Edit /etc/yum.conf and set debuglevel=0
- Make sure you have yum-utils
- see if you have any updates:
yum check-update 4. if you have updates, to download only: yumdownloader `yum check-update | awk {'print $1'}`
Thanks - after seeing your other message I was just about to point out that you have to tell it what to download and the whole point of using yum is that you don't have to know ahead of time... Seems odd that it doesn't have a shorthand notation to do that by itself, though.
Also, yumdownloader doesn't allow "--enablerepo=" the way yum does.
I have "enabled=0" in all of my repos except for base and updates. When I need something from Dag, I run "yum install foo --enablerepo=dag". The only way to do this with yumdownloader is to edit /etc/yum.repos.d/*.
Having "-downloadonly" in yum is easier.
-David, offering his 2 cents worth
On Thu, 2006-04-27 at 14:07 -0400, Lists wrote:
On Tue, 25 Apr 2006, Les Mikesell wrote:
On Tue, 2006-04-25 at 17:26, Johnny Hughes wrote:
We are looking into using a yum 2.4.x w/centos3 if possible
Please don't break the ability in Centos3 to 'yum --download-only update' followed by a later 'yum update' to be able to more accurately schedule the time an update and possible reboot will be completed. That feature seems to have disappeared in the newer versions.
There is a yum-plugin called "yumdownloader" ... it is part up yum- utils.
it is a utility and not a plugin ... sorry ... here is how you can do it:
- Edit /etc/yum.conf and set debuglevel=0
- Make sure you have yum-utils
- see if you have any updates:
yum check-update 4. if you have updates, to download only: yumdownloader `yum check-update | awk {'print $1'}`
Thanks - after seeing your other message I was just about to point out that you have to tell it what to download and the whole point of using yum is that you don't have to know ahead of time... Seems odd that it doesn't have a shorthand notation to do that by itself, though.
Also, yumdownloader doesn't allow "--enablerepo=" the way yum does.
I have "enabled=0" in all of my repos except for base and updates. When I need something from Dag, I run "yum install foo --enablerepo=dag". The only way to do this with yumdownloader is to edit /etc/yum.repos.d/*.
Having "-downloadonly" in yum is easier.
-David, offering his 2 cents worth
Lots of things are easier ... however, I didn't write yum :)
I did not say that I thought that option should have been removed :) (in fact I think it is quite handy).
It is not there, however.
On 4/25/06, Dag Wieers dag@wieers.com wrote:
I thought perl could be perfectly happy with multiple versions living on the same machine as long as you keep your paths straight. There should be no need to replace the existing one to install something newer.
Sure, I can make a package that adds the same version (or a newer version) of perl available alongside the current one. Would it be advisable ? No.
I'd much rather have a 2nd copy of just about anything than a non-standard modification to a distribution file. When that gets too unwieldy, it's time for a new distribution anyway.
User wants to install amavisd-new. Repository has amavisd-new 2.3.3 and 2.4.0. Package amavisd-new 2.4.0 has a missing dependency (unless you replace a core package)
Yum will fail to work as it will only consider version 2.4.0 in resolving dependencies. Apt and smart will correctly install the latest package.
According to the Yum developers this situation is a repository problem. But I disagree, I should be able to provide packages (like version 2.4.0) to people that are able to fix the dependencies manually without blocking _all_ other users.
Why not have a separate repository for people who want to replace core files so the ones who don't will never have to deal with this problem?
Also, other repositories might wish to choose to offer a perl replacement package, unlocking the situation for amavisd-new 2.4.0. So the argument that the repository has a problem is a fallacy and is only true if you consider a repository to be self-consistent. And the _only_ self-consistent repository there is, is the original OS repository.
Yes, that's the point of having an original OS repository, isn't it? What good is it you clobber it's consistency?
Now, regarding your statement about installing 2 programs alongside each other. Often programs don't even work if they are installed together
In that case it's poorly designed (except perhaps for the kernel and init) and you shouldn't run either copy.
and there is little need for normal users to have multiple versions (except in certain cases).
Those 'certain cases' happen. Especially in the RH scheme where if you want a stable kernel you never get any new app versions.
Besides, developers seldom use RPMs for simply testing their applications.
Obviously, or they would unstand the issue and not make it hard for other people to test them too - without breaking their working versions.
Besides that, RPM does allow different versions to be installed at the same time, using the same rules as allowing 2 different editors to be installed at the same time. It's just a discussion about semantics.
OK, give them different names instead of conflicting ones then.
-- Les Mikesell lesmikesell@gmail.com
Ralph Angenendt wrote:
So I don't think that this is a yum bug, this is a bug in RedHat's perl packaging, as you are not able to override modules which are included with the core perl package. And that hasn't change up to FC5.
I don't understand your point (I'm sorry being a perl ignorant) dag's amavisd-new works fine in centos4 because the needed perl packages versions exist: In this particular case, the needed perl packages simply do not exist in the centos 3 repositories. In order to make amavis package version work in centos3, shouldn't these new perl packages be added in the repo? What is the problem of doing that? (except that someone must do it...)
Hi
On Mon 24-Apr-2006 at 12:11:53PM +0200, Ralph Angenendt wrote:
So I don't think that this is a yum bug, this is a bug in RedHat's perl packaging, as you are not able to override modules which are included with the core perl package. And that hasn't change up to FC5.
I found that the CGI.pm in FC5's Perl doesn't work with an application I was installing [1] and after working out which was the latest version needed I packaged CGI.pm using cpanflute2 and then installed it and didn't have a problem... Of course this is overriding a module with a older version...
Chris
[1] http://www.mkdoc.org/bugs/stable/normal/cgi-pm-311/
On 4/23/06, sophana sophana@zizi.ath.cx wrote:
did some investigations # yum install amavisd-new Gathering header information file(s) from server(s) Server: CentOS-3.3 - Addons Server: ATrpms for rhel 3 stable Server: ATrpms for rhel 3 testing Server: CentOS-3.3 - Base Server: CentOS-3.3 - Extras Server: Dag RPM Repository for Red Hat Enterprise Linux Server: dries el3 repo Server: CentOS-3.3 - Extras Server: kde-redhat.org (kde-stable) Server: kde-redhat.org (kde-stable-all) Server: CentOS-3.3 - Updates Finding updated packages Downloading needed headers Resolving dependencies ......Unable to satisfy dependencies Package amavisd-new needs perl(Digest::MD5) >= 2.22, this is not available. Package amavisd-new needs perl(Time::HiRes) >= 1.49, this is not available.
perl-Time-HiRes is version 1.38 in the centos 3 repo. So this is normal it doesn't work.
Do you think you're mixing enough 3rd party repositories there? You've got 2 that I wouldn't touch at all... ATrpms stable, and ATrpms testing. ATrpms has a nasty reputation for replacing system packages, and generally being unstable (meaning you can quickly wreck your system using it).
however I don't understand this bug: # yum install rpm Gathering header information file(s) from server(s) Server: CentOS-3.3 - Addons Server: ATrpms for rhel 3 stable Server: ATrpms for rhel 3 testing Server: CentOS-3.3 - Base Server: CentOS-3.3 - Extras Server: Dag RPM Repository for Red Hat Enterprise Linux Server: dries el3 repo Server: CentOS-3.3 - Extras Server: kde-redhat.org (kde-stable) Server: kde-redhat.org (kde-stable-all) Server: CentOS-3.3 - Updates Finding updated packages Downloading needed headers Resolving dependencies .......Unable to satisfy dependencies Package rpm-libs needs rpm = 4.2.3-24_nonptl, this is not available. # rpm -q rpm rpm-4.2.3-10 # ls /var/cache/yum/base/headers/rpm-libs* /var/cache/yum/base/headers/rpm-libs-0-4.2.3-21_nonptl.i386.hdr /var/cache/yum/base/headers/rpm-libs-0-4.2.3-24_nonptl.i386.hdr
I noticed lots of bugs in yum. This is really annoying.
This looks like the rpm-libs package its trying to update doesn't have a matching rpm for rpm. I'd say that this is likely due to the number of repositories you're using, and likely a direct result of mixing ATrpms with all the other repos. This goes back to what I mentioned earlier about doing destructive things to your system. It's not a problem of yum, etc.. but rather the expected result of mixing so many repositories, and in particular 2 very unstable repos.
-- This message has been double ROT13 encoded for security. Anyone other than the intended recipient attempting to decode this message will be in violation of the DMCA
Jim Perrin wrote:
On 4/23/06, sophana sophana@zizi.ath.cx wrote:
did some investigations # yum install amavisd-new Gathering header information file(s) from server(s) Server: CentOS-3.3 - Addons Server: ATrpms for rhel 3 stable Server: ATrpms for rhel 3 testing Server: CentOS-3.3 - Base Server: CentOS-3.3 - Extras Server: Dag RPM Repository for Red Hat Enterprise Linux Server: dries el3 repo Server: CentOS-3.3 - Extras Server: kde-redhat.org (kde-stable) Server: kde-redhat.org (kde-stable-all) Server: CentOS-3.3 - Updates Finding updated packages Downloading needed headers Resolving dependencies ......Unable to satisfy dependencies Package amavisd-new needs perl(Digest::MD5) >= 2.22, this is not available. Package amavisd-new needs perl(Time::HiRes) >= 1.49, this is not available.
perl-Time-HiRes is version 1.38 in the centos 3 repo. So this is normal it doesn't work.
Do you think you're mixing enough 3rd party repositories there? You've got 2 that I wouldn't touch at all... ATrpms stable, and ATrpms testing. ATrpms has a nasty reputation for replacing system packages, and generally being unstable (meaning you can quickly wreck your system using it).
you're right. I forgot to remove atrpms test. Note that I never do a general yum update. So my system should not be totally wrecked.
however I don't understand this bug: # yum install rpm Gathering header information file(s) from server(s) Server: CentOS-3.3 - Addons Server: ATrpms for rhel 3 stable Server: ATrpms for rhel 3 testing Server: CentOS-3.3 - Base Server: CentOS-3.3 - Extras Server: Dag RPM Repository for Red Hat Enterprise Linux Server: dries el3 repo Server: CentOS-3.3 - Extras Server: kde-redhat.org (kde-stable) Server: kde-redhat.org (kde-stable-all) Server: CentOS-3.3 - Updates Finding updated packages Downloading needed headers Resolving dependencies .......Unable to satisfy dependencies Package rpm-libs needs rpm = 4.2.3-24_nonptl, this is not available. # rpm -q rpm rpm-4.2.3-10 # ls /var/cache/yum/base/headers/rpm-libs* /var/cache/yum/base/headers/rpm-libs-0-4.2.3-21_nonptl.i386.hdr /var/cache/yum/base/headers/rpm-libs-0-4.2.3-24_nonptl.i386.hdr
I noticed lots of bugs in yum. This is really annoying.
This looks like the rpm-libs package its trying to update doesn't have a matching rpm for rpm. I'd say that this is likely due to the number of repositories you're using, and likely a direct result of mixing ATrpms with all the other repos. This goes back to what I mentioned earlier about doing destructive things to your system. It's not a problem of yum, etc.. but rather the expected result of mixing so many repositories, and in particular 2 very unstable repos.
Sorry, I did the wrong ls. The needed package does exist:
# ls rpm-0* rpm-0-4.2.3-21_nonptl.i386.hdr rpm-0-4.2.3-24_nonptl.i386.hdr
Isn't it a bug? The problem is that I would like to use apt or smart, but I'm blocked because of that.
you're right. I forgot to remove atrpms test. Note that I never do a general yum update. So my system should not be totally wrecked.
Except that it only takes one 'yum install' from ATrpms to replace a couple of important core packages or install one thats incompatible with upstream, thus causing your dilemma. Also note that if you never do a yum update, then you're missing several important updates. If you are indeed on 3.3 like you said earlier, then you're a little over a year out of date. There have been several important bugs fixed, and a couple critical ones which could potentially leave your system open to intruders. It may not be wrecked from installed packages, but negligence instead. Is there a reason to not perform basic upgrade tasks like 'yum update' (aside from the obvious now where it won't work)?
-- This message has been double ROT13 encoded for security. Anyone other than the intended recipient attempting to decode this message will be in violation of the DMCA
Jim Perrin wrote:
you're right. I forgot to remove atrpms test. Note that I never do a general yum update. So my system should not be totally wrecked.
Except that it only takes one 'yum install' from ATrpms to replace a couple of important core packages or install one thats incompatible with upstream, thus causing your dilemma. Also note that if you never do a yum update, then you're missing several important updates. If you are indeed on 3.3 like you said earlier, then you're a little over a year out of date. There have been several important bugs fixed, and a couple critical ones which could potentially leave your system open to intruders. It may not be wrecked from installed packages, but negligence instead. Is there a reason to not perform basic upgrade tasks like 'yum update' (aside from the obvious now where it won't work)?
Ok, I'll be watching close.
But you did not explain why the rpm dependency was failing: Is it a yum bug?
.......Unable to satisfy dependencies Package rpm-libs needs rpm = 4.2.3-24_nonptl, this is not available. # rpm -q rpm rpm-4.2.3-10 # ls /var/cache/yum/base/headers/rpm-0* rpm-0-4.2.3-21_nonptl.i386.hdr rpm-0-4.2.3-24_nonptl.i386.hdr
Is there a reason to not perform basic upgrade tasks like 'yum update' (aside from the obvious now where it won't work)?
Ok, I'll be watching close.
I'm not sure how 'OK' fits as an answer to that question, but so long as you're aware of what you're doing, I'm not one to judge.
But you did not explain why the rpm dependency was failing:
Something is horked in your system, and we don't have enough detail yet to know why it's failing to upgrade rpm.
Is it a yum bug?
Dag covered part of this already. Part of what you're seeing is related to crap on your system, and the other part is something that some call a bug and some don't. I don't see it as a bug, but it's also not the way I'd expect yum to act.
-- This message has been double ROT13 encoded for security. Anyone other than the intended recipient attempting to decode this message will be in violation of the DMCA
So what should I do now? I did a rpm --rebuild-db nothing changes. I will try to remove repos, maybe install rpm by hand.
Jim Perrin wrote:
Is there a reason to not perform basic upgrade tasks like 'yum update' (aside from the obvious now where it won't work)?
Ok, I'll be watching close.
I'm not sure how 'OK' fits as an answer to that question, but so long as you're aware of what you're doing, I'm not one to judge.
But you did not explain why the rpm dependency was failing:
Something is horked in your system, and we don't have enough detail yet to know why it's failing to upgrade rpm.
Is it a yum bug?
Dag covered part of this already. Part of what you're seeing is related to crap on your system, and the other part is something that some call a bug and some don't. I don't see it as a bug, but it's also not the way I'd expect yum to act.
-- This message has been double ROT13 encoded for security. Anyone other than the intended recipient attempting to decode this message will be in violation of the DMCA _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
--- sophana sophana@zizi.ath.cx wrote:
I have an old centos 3.3, and cannot update because
of broken dependencies.
You have are running a circus not a server. Even in the fedora world you cannot enable those many repos and hope to run properly.
Do us all a favour and do the following:-
- mark your present server as a "circus" and leave it in the corner.
- get a clean CentOS 3.7 server that has base and updates enabled.Install all available updates.
- Install the rpmforge release and install amavisd.
- Tell us the results. Next time don't enable all those repos/fail to apply official updates and complain.
- read on yum plugins and the important role they prevent in protecting base.
- search google for "problems mixing repositories"
__________________________________________________ Improve the mailing list by performing a simple search before posting and reading the FAQ/etiquette. Protect the integrity of your installation with the yum plugins.
__________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
On 4/23/06, Dag Wieers dag@wieers.com wrote:
On Fri, 21 Apr 2006, Leonard Isham wrote:
On 4/20/06, sophana sophana@zizi.ath.cx wrote:
Hi
I'm trying to install amavisd-new from dag repo on centos3. In the spec file perl dependencies use parenthesis: perl(Digest::MD5) it also uses '-': perl-MailTools
The problem is that only the second notation is available: perl-MD5
I know this is an old problem. Is this only centos related? Is there a workaround?
Do I have to modify the spec file? I'd like to use yum...
I use amavisd-new as well.
I ran into some Per modules missing when using Dag. I switched to using RPMForge, which is a merger of Dag, Dries, and maybe one or two more. Since then I have not had the problem.
Next time, do us all a favor and report if something is not working.
Kind regards, -- dag wieers, dag@wieers.com, http://dag.wieers.com/ -- [all I want is a warm bed and a kind word and unlimited power]
An apology to Dag. I assumed that the goal was to move everyone to RPMForge, and I was late in making the trasition.
-- Leonard Isham, CISSP Ostendo non ostento.
On Sun, 23 Apr 2006, Leonard Isham wrote:
On 4/23/06, Dag Wieers dag@wieers.com wrote:
On Fri, 21 Apr 2006, Leonard Isham wrote:
On 4/20/06, sophana sophana@zizi.ath.cx wrote:
Hi
I'm trying to install amavisd-new from dag repo on centos3. In the spec file perl dependencies use parenthesis: perl(Digest::MD5) it also uses '-': perl-MailTools
The problem is that only the second notation is available: perl-MD5
I know this is an old problem. Is this only centos related? Is there a workaround?
Do I have to modify the spec file? I'd like to use yum...
I use amavisd-new as well.
I ran into some Per modules missing when using Dag. I switched to using RPMForge, which is a merger of Dag, Dries, and maybe one or two more. Since then I have not had the problem.
Next time, do us all a favor and report if something is not working.
An apology to Dag. I assumed that the goal was to move everyone to RPMForge, and I was late in making the trasition.
No apology needed, but I hate to get late feedback like this. If you have a problem, report it !
Every report that says something like "I have seen that as well and I fixed it by doing..." is frustrating because I could have fixed it as well and the problem would be there anymore in the first place for anyone.
I understand that if you have a problem and you need to get forward, you fix it first. That's normal. But if it is fixed, report it. The reason why you only got that problem, was because other people have been nice and reported other problems that you didn't have to deal with anylonger.
The reason why Linux even works is because other people made it work and took the time to report problems and fix things. So not having the time to report something, while obviously having the time to reply on the mailinglist for the very same issue is frustrating :)
BTW RPMforge == Dag if you're using EL3 or EL4, there is no difference. The aim with RPMforge is to try and make people help a project instead of an individual, but apparently it is not working very well :/
Kind regards, -- dag wieers, dag@wieers.com, http://dag.wieers.com/ -- [all I want is a warm bed and a kind word and unlimited power]
BTW RPMforge == Dag if you're using EL3 or EL4, there is no difference. The aim with RPMforge is to try and make people help a project instead of an individual, but apparently it is not working very well :/
Dag,
What type of help were you looking for? Obviously your work has made significant contributions to the community so I would hope that people here would be happy to help our so if you could push a bit about what people could do it would be helpful.
--Bill
On 4/24/06, Dag Wieers dag@wieers.com wrote:
On Sun, 23 Apr 2006, Leonard Isham wrote:
On 4/23/06, Dag Wieers dag@wieers.com wrote:
On Fri, 21 Apr 2006, Leonard Isham wrote:
On 4/20/06, sophana sophana@zizi.ath.cx wrote:
Hi
I'm trying to install amavisd-new from dag repo on centos3. In the spec file perl dependencies use parenthesis: perl(Digest::MD5) it also uses '-': perl-MailTools
The problem is that only the second notation is available: perl-MD5
I know this is an old problem. Is this only centos related? Is there a workaround?
> Do I have to modify the spec file? I'd like to use yum...
I use amavisd-new as well.
I ran into some Per modules missing when using Dag. I switched to using RPMForge, which is a merger of Dag, Dries, and maybe one or two more. Since then I have not had the problem.
Next time, do us all a favor and report if something is not working.
An apology to Dag. I assumed that the goal was to move everyone to RPMForge, and I was late in making the trasition.
No apology needed, but I hate to get late feedback like this. If you have a problem, report it !
Every report that says something like "I have seen that as well and I fixed it by doing..." is frustrating because I could have fixed it as well and the problem would be there anymore in the first place for anyone.
I understand that if you have a problem and you need to get forward, you fix it first. That's normal. But if it is fixed, report it. The reason why you only got that problem, was because other people have been nice and reported other problems that you didn't have to deal with anylonger.
The reason why Linux even works is because other people made it work and took the time to report problems and fix things. So not having the time to report something, while obviously having the time to reply on the mailinglist for the very same issue is frustrating :)
BTW RPMforge == Dag if you're using EL3 or EL4, there is no difference. The aim with RPMforge is to try and make people help a project instead of an individual, but apparently it is not working very well :/
I for one am grateful for what you, all of the repository maintainers, do.
Since I use a few repositories, and I know if I break it I get to keep the pieces. I assumed it was not specific to your repository at the time I was trouleshooting it. I then moved to RPMForge and later realized that it didn't happen anymore...
-- Leonard Isham, CISSP Ostendo non ostento.
-
Chris Croome -
Dag Wieers -
Jim Perrin -
Johnny Hughes -
Leonard Isham -
Les Mikesell -
Lists -
Mike Stankovic -
Ralph Angenendt -
sophana -
William E. T. -
William L. Maltby