The files /etc/yum.repos.d/* have moved from yumconf into centos-release.
I don't know if this is planned but the net result is it broke my yum config (again) and unless there is a good reason I don't know of, it seems broken.
I have a site specific /etc/yum.conf and I don't want any files in /etc/yum.repos.d/
I have a custom yumconf packages which prevents the centos version from installing the files in /etc/yum.repos.d/ but that is no longer effective.
Any ideas?
John Newbigin wrote:
I have a custom yumconf packages which prevents the centos version from installing the files in /etc/yum.repos.d/ but that is no longer effective.
Any ideas?
how about your own package provide a yumconf and a centos-release ? that way you can effectively lock out the Centos-distro-yum config's
Karanbir Singh wrote:
John Newbigin wrote:
how about your own package provide a yumconf and a centos-release ? that way you can effectively lock out the Centos-distro-yum config's
I still need the real files from centos-release (such as /etc/redhat-release) which may change from time to time (when 4.5 comes out). I could create my own replacement but I think that the files belong in the yumconf package and this may well be a centos bug.
I still need the real files from centos-release (such as /etc/redhat-release) which may change from time to time (when 4.5 comes out). I could create my own replacement but I think that the files belong in the yumconf package and this may well be a centos bug.
This also causes a related issue for RHEL users who want to use yum. In posts to the yum mailing list, it's often recommended that RHEL users grab yum from the centos repositories. As of the 4.4 release, they can no longer do this as yum requires yumconf, provided by centos-release, which will overwrite their /etc/redhat-release, and /etc/sysconfig/rhn/sources files among others. This either keeps them from using our yum packages, or forces them to migrate to centos which they may not be aware of if they install centos-release without thinking it through.
I see this as an interoperability issue, and it should be discussed a bit. I'm not convinced that a yumconf package is the way to go, but providing the files in centos-release doesn't seem to be the right way either. Other opinions?
Jim Perrin wrote:
I still need the real files from centos-release (such as /etc/redhat-release) which may change from time to time (when 4.5 comes out). I could create my own replacement but I think that the files belong in the yumconf package and this may well be a centos bug.
I see this as an interoperability issue, and it should be discussed a bit. I'm not convinced that a yumconf package is the way to go, but providing the files in centos-release doesn't seem to be the right way either. Other opinions?
if the files are (config) type, then a locally user modified version will superseed the new rpm based one, and will result in your config's being left alone with the new files being dropped as .rpmnew
I'd presume this is what happened ?
if the files are (config) type, then a locally user modified version will superseed the new rpm based one, and will result in your config's being left alone with the new files being dropped as .rpmnew I'd presume this is what happened ?
Not in this instance no. 90% of users have no reason to modify /etc/issue, /etc/redhat-release, or /etc/sysconfig/rhn/sources, so these files will be overwritten most of the time. While adjusting our packages so that they can be used on both RHEL and centos isn't exactly a centos specific concern, it is the neighborly thing to do.
On Wed, 2006-09-06 at 01:01 +0100, Karanbir Singh wrote:
Jim Perrin wrote:
I still need the real files from centos-release (such as /etc/redhat-release) which may change from time to time (when 4.5 comes out). I could create my own replacement but I think that the files belong in the yumconf package and this may well be a centos bug.
I see this as an interoperability issue, and it should be discussed a bit. I'm not convinced that a yumconf package is the way to go, but providing the files in centos-release doesn't seem to be the right way either. Other opinions?
if the files are (config) type, then a locally user modified version will superseed the new rpm based one, and will result in your config's being left alone with the new files being dropped as .rpmnew
I'd presume this is what happened ?
The purpose of this change is so that we mirror what is done by upstream.
They provide their update sources in redhat-release file.
A separate RPM for yumconf (and up2date-conf) is redundant.
Have it be part of yum or up2date is bad ...
I have no problem with a sperate yumconf package, but it is not in keeping with upstream.
If you produce a package with a new CentOS-Base.repo (and force install it) that overwrites the other file, then when new updates happen it will produce rpmnew files and should not affect you at all.
As I said ... i can be easily convinced to to shift back, but shouldn't we try to do things like upstream?
Johnny Hughes wrote:
if the files are (config) type, then a locally user modified version will superseed the new rpm based one, and will result in your config's being left alone with the new files being dropped as .rpmnew
I'd presume this is what happened ?
The problem is an rpm issue where if you delete a config file, it will 'come back' when an update is installed.
The purpose of this change is so that we mirror what is done by upstream.
They provide their update sources in redhat-release file.
A separate RPM for yumconf (and up2date-conf) is redundant.
Have it be part of yum or up2date is bad ...
I have no problem with a sperate yumconf package, but it is not in keeping with upstream.
Does the upstream contain the yum confg files? If not then I don't think CentOS should be adding the files there. I don't use up2date so I can't comment on that.
In the past CentOS (yum) has required a yumconf, which is still the case.
The finger could also be pointed at yum. Perhaps I need to change my reposdir config.
John.
If you produce a package with a new CentOS-Base.repo (and force install it) that overwrites the other file, then when new updates happen it will produce rpmnew files and should not affect you at all.
As I said ... i can be easily convinced to to shift back, but shouldn't we try to do things like upstream?
CentOS-devel mailing list CentOS-devel@centos.org http://lists.centos.org/mailman/listinfo/centos-devel
On Wed, 2006-09-06 at 11:28 +1000, John Newbigin wrote:
Johnny Hughes wrote:
if the files are (config) type, then a locally user modified version will superseed the new rpm based one, and will result in your config's being left alone with the new files being dropped as .rpmnew
I'd presume this is what happened ?
The problem is an rpm issue where if you delete a config file, it will 'come back' when an update is installed.
The purpose of this change is so that we mirror what is done by upstream.
what's 'the upstream' in this case?
You mean where fedora is putting it?
-sv
On Tue, 2006-09-05 at 22:56 -0400, seth vidal wrote:
On Wed, 2006-09-06 at 11:28 +1000, John Newbigin wrote:
Johnny Hughes wrote:
if the files are (config) type, then a locally user modified version will superseed the new rpm based one, and will result in your config's being left alone with the new files being dropped as .rpmnew
I'd presume this is what happened ?
The problem is an rpm issue where if you delete a config file, it will 'come back' when an update is installed.
The purpose of this change is so that we mirror what is done by upstream.
what's 'the upstream' in this case?
You mean where fedora is putting it?
not specific to yum configs, but just config files for updates in general. rhn sources file, yum config, etc.
In RHEL , the RHN files are included in redhat-release.
On Tue, 2006-09-05 at 22:32 -0500, Johnny Hughes wrote:
On Tue, 2006-09-05 at 22:56 -0400, seth vidal wrote:
On Wed, 2006-09-06 at 11:28 +1000, John Newbigin wrote:
Johnny Hughes wrote:
if the files are (config) type, then a locally user modified version will superseed the new rpm based one, and will result in your config's being left alone with the new files being dropped as .rpmnew
I'd presume this is what happened ?
The problem is an rpm issue where if you delete a config file, it will 'come back' when an update is installed.
The purpose of this change is so that we mirror what is done by upstream.
what's 'the upstream' in this case?
You mean where fedora is putting it?
not specific to yum configs, but just config files for updates in general. rhn sources file, yum config, etc.
In RHEL , the RHN files are included in redhat-release. _______________________________________________
Sorry ... I did also mean to say that Fedora Core does do the same thing with their yum.repos.d conf files too ... they are in fedora-release.
On Wed, 2006-09-06 at 11:28 +1000, John Newbigin wrote:
Johnny Hughes wrote:
if the files are (config) type, then a locally user modified version will superseed the new rpm based one, and will result in your config's being left alone with the new files being dropped as .rpmnew
I'd presume this is what happened ?
The problem is an rpm issue where if you delete a config file, it will 'come back' when an update is installed.
Don't delete it, replace it with either a neutered file (if you want to use a different name) ... or replace it with your repo file ... named the same thing.
It will then never be updated again, but be created as rpmnew when updates happen.
The purpose of this change is so that we mirror what is done by upstream.
They provide their update sources in redhat-release file.
A separate RPM for yumconf (and up2date-conf) is redundant.
Have it be part of yum or up2date is bad ...
I have no problem with a sperate yumconf package, but it is not in keeping with upstream.
Does the upstream contain the yum confg files? If not then I don't think CentOS should be adding the files there. I don't use up2date so I can't comment on that.
RHEL-4 doesn't contain yum, however the rhn sources file is in redhat- release.
As I said, we can change it back if it is a huge problem, but it makes since to do all the update sources in one file (CentOS release).
Then, if you want to make your own distro ... replace that one file and all your update streams can be adjusted.
Splitting out the files from the base package (as we did for apt and up2date and yum) also allows you to use a yum or apt or up2date from a different repo (3rd party) and still get centos updates.
In the past CentOS (yum) has required a yumconf, which is still the case.
The finger could also be pointed at yum. Perhaps I need to change my reposdir config.
John.
If you produce a package with a new CentOS-Base.repo (and force install it) that overwrites the other file, then when new updates happen it will produce rpmnew files and should not affect you at all.
As I said ... i can be easily convinced to to shift back, but shouldn't we try to do things like upstream?
Johnny Hughes wrote:
[...] Don't delete it, replace it with either a neutered file (if you want to use a different name) ... or replace it with your repo file ... named the same thing. [...]
In SME Server land we use centos-release unmodified and provide our own smeserver-release. We also have an smeserver-yum package which does this:
Provides: yumconf Conflicts: centos-yumconf
so that the CentOS repo files don't get installed at all.
So, the change in this thread will bite us. It's a moot point in our case as we are planning to re-enable the CentOS base and updates repos in our next release, but I would support keeping the packages separate.
How about building [centos-]yumconf from the centos-release SPEC file?
Thanks,
Gordon
On Tue, 2006-09-05 at 22:40 -0500, Johnny Hughes wrote:
The purpose of this change is so that we mirror what is done by upstream.
They provide their update sources in redhat-release file.
A separate RPM for yumconf (and up2date-conf) is redundant.
Have it be part of yum or up2date is bad ...
I have no problem with a sperate yumconf package, but it is not in keeping with upstream.
Does the upstream contain the yum confg files? If not then I don't think CentOS should be adding the files there. I don't use up2date so I can't comment on that.
RHEL-4 doesn't contain yum, however the rhn sources file is in redhat- release.
As I said, we can change it back if it is a huge problem, but it makes since to do all the update sources in one file (CentOS release).
Then, if you want to make your own distro ... replace that one file and all your update streams can be adjusted.
This is what I did yesterday for duke's internal centos 4 release. I just made a new centos-release and was done.
-sv
Johnny Hughes wrote:
The purpose of this change is so that we mirror what is done by upstream.
They provide their update sources in redhat-release file.
A separate RPM for yumconf (and up2date-conf) is redundant.
Have it be part of yum or up2date is bad ...
I have no problem with a sperate yumconf package, but it is not in keeping with upstream.
If you produce a package with a new CentOS-Base.repo (and force install it) that overwrites the other file, then when new updates happen it will produce rpmnew files and should not affect you at all.
As I said ... i can be easily convinced to to shift back, but shouldn't we try to do things like upstream?
I also think the old way was better. We have our own "centos-yumconf-local" package, which does an "Obsoletes: centos-yumconf", so as soon as we added our local repo to a new system (containing this package), it would automatically update to our own yum configuration.
Now that does not work anymore, and I would have to replace centos-release to get the same effect. I will have to rebuild this centos-release package for every CentOS release. It's no big deal, because I also have to rebuild other packages for each major release (e.g. glibc for Xen), but I still wanted to say that I preferred the old way.
Perhaps building the centos-yumconf rpm from the centos-release src rpm, like Gordon suggested, is a good plan?
Best Regards, Michael Paesold
Michael Paesold wrote:
Now that does not work anymore, and I would have to replace centos-release to get the same effect. I will have to rebuild this centos-release package for every CentOS release.
Won't this also cause problems when upgrading to the next release?
John Summerfied wrote:
Michael Paesold wrote:
Now that does not work anymore, and I would have to replace centos-release to get the same effect. I will have to rebuild this centos-release package for every CentOS release.
Won't this also cause problems when upgrading to the next release?
Of course it will. :-(
With number of unhappy people I have seen on this list now, I would ask the CentOS maintainers to change that back so that the former yumconf files come from a separate package (if it comes from a single src.rpm, that's perfectly OK).
Although I understand the arguments for the change, I think going back to how it was done before is the lesser of both evils. Just IMHO.
Best Regards, Michael Paesold
On Thu, Sep 07, 2006 at 03:38:26PM +0200, Michael Paesold enlightened us:
John Summerfied wrote:
Michael Paesold wrote:
Now that does not work anymore, and I would have to replace centos-release to get the same effect. I will have to rebuild this centos-release package for every CentOS release.
Won't this also cause problems when upgrading to the next release?
Of course it will. :-(
Not with proper exclude= lines in your configuration it won't. After all, since you made the centos-release package yourself, you can control what goes in that file, so an exclude line should be trivial.
Matt Hyclak wrote:
On Thu, Sep 07, 2006 at 03:38:26PM +0200, Michael Paesold enlightened us:
John Summerfied wrote:
Michael Paesold wrote:
Now that does not work anymore, and I would have to replace centos-release to get the same effect. I will have to rebuild this centos-release package for every CentOS release.
Won't this also cause problems when upgrading to the next release?
Of course it will. :-(
Not with proper exclude= lines in your configuration it won't. After all, since you made the centos-release package yourself, you can control what goes in that file, so an exclude line should be trivial.
Eh? Doesn't Anaconda look at the release file to see what it's supposed to upgrade _from_? If it doesn't recognise it, how will it know how to upgrade?
On Thu, Sep 07, 2006 at 10:09:08PM +0800, John Summerfield enlightened us:
Matt Hyclak wrote:
Won't this also cause problems when upgrading to the next release?
Of course it will. :-(
Not with proper exclude= lines in your configuration it won't. After all, since you made the centos-release package yourself, you can control what goes in that file, so an exclude line should be trivial.
Eh? Doesn't Anaconda look at the release file to see what it's supposed to upgrade _from_? If it doesn't recognise it, how will it know how to upgrade?
Have we moved away from yum into respun CDs?
Matt Hyclak wrote:
On Thu, Sep 07, 2006 at 10:09:08PM +0800, John Summerfield enlightened us:
Matt Hyclak wrote:
Won't this also cause problems when upgrading to the next release?
Of course it will. :-(
Not with proper exclude= lines in your configuration it won't. After all, since you made the centos-release package yourself, you can control what goes in that file, so an exclude line should be trivial.
Eh? Doesn't Anaconda look at the release file to see what it's supposed to upgrade _from_? If it doesn't recognise it, how will it know how to upgrade?
Have we moved away from yum into respun CDs?
No, I was thinking of the upgrade many folk will want to do to CentOS 5.
If folk are creating alternative release packages I wonder whether they will create problems for themselves at that time.
While Anaconda has an argument to force it to upgrade, and it would almost certainly work upgrading CentOS4 (or even WBEL) to CentOS5, it's not the sort of thing people should use in the ordinary course of events.
On Thu, 2006-09-07 at 22:35 +0800, John Summerfield wrote:
Matt Hyclak wrote:
On Thu, Sep 07, 2006 at 10:09:08PM +0800, John Summerfield enlightened us:
Matt Hyclak wrote:
Won't this also cause problems when upgrading to the next release?
Of course it will. :-(
Not with proper exclude= lines in your configuration it won't. After all, since you made the centos-release package yourself, you can control what goes in that file, so an exclude line should be trivial.
Eh? Doesn't Anaconda look at the release file to see what it's supposed to upgrade _from_? If it doesn't recognise it, how will it know how to upgrade?
Have we moved away from yum into respun CDs?
No, I was thinking of the upgrade many folk will want to do to CentOS 5.
If folk are creating alternative release packages I wonder whether they will create problems for themselves at that time.
While Anaconda has an argument to force it to upgrade, and it would almost certainly work upgrading CentOS4 (or even WBEL) to CentOS5, it's not the sort of thing people should use in the ordinary course of events.
pretty sure red hat doesn't support upgrades between major release versions.
so I can't imagine it'll be supported in anything from 4 -> 5.
-sv
seth vidal wrote:
On Thu, 2006-09-07 at 22:35 +0800, John Summerfield wrote:
Matt Hyclak wrote:
On Thu, Sep 07, 2006 at 10:09:08PM +0800, John Summerfield enlightened us:
Matt Hyclak wrote:
>Won't this also cause problems when upgrading to the next release?
Of course it will. :-(
Not with proper exclude= lines in your configuration it won't. After all, since you made the centos-release package yourself, you can control what goes in that file, so an exclude line should be trivial.
Eh? Doesn't Anaconda look at the release file to see what it's supposed to upgrade _from_? If it doesn't recognise it, how will it know how to upgrade?
Have we moved away from yum into respun CDs?
No, I was thinking of the upgrade many folk will want to do to CentOS 5.
If folk are creating alternative release packages I wonder whether they will create problems for themselves at that time.
While Anaconda has an argument to force it to upgrade, and it would almost certainly work upgrading CentOS4 (or even WBEL) to CentOS5, it's not the sort of thing people should use in the ordinary course of events.
pretty sure red hat doesn't support upgrades between major release versions.
I'm next to certain it does. It supported upgrades from whenever Anaconda appeard (5.x or so I think) right up to RHL 9 - even skipping releases, and upgrades to newer Fedora Core work. I don't see why upgrading RHEL 2.1 to 3 or 4 would not work.
There might be some manual work to do, replacing dropped packed (eg imapd) with newer (eg cyrus-imapd).
so I can't imagine it'll be supported in anything from 4 -> 5.
and I'll be fairly surprised if it's not:-)
One thin I have in mind is to try to upgrade RHL 7.3 to Centos 3 or 4 at some point. I fully expect to apply a little force in that case; that is what it's for (not a supported upgrade but probably will work).
John Summerfield wrote:
seth vidal wrote:
On Thu, 2006-09-07 at 22:35 +0800, John Summerfield wrote:
Matt Hyclak wrote:
On Thu, Sep 07, 2006 at 10:09:08PM +0800, John Summerfield enlightened us:
Matt Hyclak wrote:
>> Won't this also cause problems when upgrading to the next release? > > Of course it will. :-( >
Not with proper exclude= lines in your configuration it won't. After all, since you made the centos-release package yourself, you can control what goes in that file, so an exclude line should be trivial.
Eh? Doesn't Anaconda look at the release file to see what it's supposed to upgrade _from_? If it doesn't recognise it, how will it know how to upgrade?
Have we moved away from yum into respun CDs?
No, I was thinking of the upgrade many folk will want to do to CentOS 5.
If folk are creating alternative release packages I wonder whether they will create problems for themselves at that time.
While Anaconda has an argument to force it to upgrade, and it would almost certainly work upgrading CentOS4 (or even WBEL) to CentOS5, it's not the sort of thing people should use in the ordinary course of events.
pretty sure red hat doesn't support upgrades between major release versions.
I'm next to certain it does. It supported upgrades from whenever Anaconda appeard (5.x or so I think) right up to RHL 9 - even skipping releases, and upgrades to newer Fedora Core work. I don't see why upgrading RHEL 2.1 to 3 or 4 would not work.
I believe the first point in the El4 release notes was that upgrades are not supported, but i might be wrong. you should check.
it might be point number 2
Karanbir Singh wrote:
John Summerfield wrote:
Eh? Doesn't Anaconda look at the release file to see what it's supposed to upgrade _from_? If it doesn't recognise it, how will it know how to upgrade?
Have we moved away from yum into respun CDs?
No, I was thinking of the upgrade many folk will want to do to CentOS 5.
If folk are creating alternative release packages I wonder whether they will create problems for themselves at that time.
While Anaconda has an argument to force it to upgrade, and it would almost certainly work upgrading CentOS4 (or even WBEL) to CentOS5, it's not the sort of thing people should use in the ordinary course of events.
pretty sure red hat doesn't support upgrades between major release versions.
I'm next to certain it does. It supported upgrades from whenever Anaconda appeard (5.x or so I think) right up to RHL 9 - even skipping releases, and upgrades to newer Fedora Core work. I don't see why upgrading RHEL 2.1 to 3 or 4 would not work.
I believe the first point in the El4 release notes was that upgrades are not supported, but i might be wrong. you should check.
it might be point number 2
You may use Anaconda to perform a fresh installation of Red Hat Enterprise Linux 4.91 or to perform an upgrade from the latest updated version of Red Hat Enterprise Linux 4 to Red Hat Enterprise Linux 4.91.
As I expected, upgrade is supported. Ill-advised tampering with the contents of the release file will cause problems, and if we encourage folk to create their own release packages, they will and some will change the contents of the releases file.
I think reverting to yumconf is preferable; we're based off RHEL, so Fedora isn't especially relevant, and we're not supporting RHN so the RHN configuration files are irrelevant to us.
If we ship a modified up2date that shares yum configuration, that's fine, our users don't want to talk to RHN anyway.
OTOH RHEL users do want to use CentOS stuff sumetimes, and a yumconf package makes that easy.
On Fri, 2006-09-08 at 09:23 +0800, John Summerfield wrote:
Karanbir Singh wrote:
John Summerfield wrote:
I'm next to certain it does. It supported upgrades from whenever Anaconda appeard (5.x or so I think) right up to RHL 9 - even skipping releases, and upgrades to newer Fedora Core work. I don't see why upgrading RHEL 2.1 to 3 or 4 would not work.
I believe the first point in the El4 release notes was that upgrades are not supported, but i might be wrong. you should check.
it might be point number 2
You may use Anaconda to perform a fresh installation of Red Hat Enterprise Linux 4.91 or to perform an upgrade from the latest updated version of Red Hat Enterprise Linux 4 to Red Hat Enterprise Linux 4.91.
That's for the beta. Not for the final.
be aware of that.
-sv
seth vidal wrote:
[...] That's for the beta. Not for the final.
be aware of that.
Though it is becoming somewhat tangential to this thread, in SME Server land support system upgrades via CD/Anaconda from RH7.3 based e-smith/SME Servers to CentOS 4.3 based SME Server 7.
We have a number of people in favour of reverting to the split yumconf.
Karanbir/Johnny/etc. - does the single SPEC file generating multiple packages work for you? If so, I'm happy to send a modified SPEC file.
Thanks,
Gordon
seth vidal wrote:
On Fri, 2006-09-08 at 09:23 +0800, John Summerfield wrote:
You may use Anaconda to perform a fresh installation of Red Hat Enterprise Linux 4.91 or to perform an upgrade from the latest updated version of Red Hat Enterprise Linux 4 to Red Hat Enterprise Linux 4.91.
That's for the beta. Not for the final.
be aware of that.
<rolls eyes>
that's completely what I expected.
q. Why would RH want users to test the uprade, if it's not to be supported in the final release? a. Dunno. See http://www.redhat.com/docs/manuals/enterprise/RHEL-4-Manual/x8664-multi-inst...
<rolls eyes>
that's completely what I expected.
q. Why would RH want users to test the uprade, if it's not to be supported in the final release? a. Dunno. See http://www.redhat.com/docs/manuals/enterprise/RHEL-4-Manual/x8664-multi-inst...
Well, since this seems to be turning into a pissing contest, lets settle this. 1. Yes, the software supports the upgrade feature. It was there in the past, it'll probably continue to be there in the future. 2. Does it work? Depends on what you've done to the system previously. The stuff you like to has a fair amount of warning sprinkled over it. 3. Will RH support it? Nope. The admin I replaced at work tried this one from RHEL3 to RHEL4. He had issues with stock RHEL software. Nothing 3rd party, nothing fancy. The support rep told him that upgrades were not supported, and to back up his data and to try to duplicate the problem on a clean install. They would not assist once they determined the box had been upgraded.
You're both right. Software supports it. People won't.
Jim Perrin wrote:
<rolls eyes>
that's completely what I expected.
q. Why would RH want users to test the uprade, if it's not to be supported in the final release? a. Dunno. See http://www.redhat.com/docs/manuals/enterprise/RHEL-4-Manual/x8664-multi-inst...
Well, since this seems to be turning into a pissing contest, lets settle this.
- Yes, the software supports the upgrade feature. It was there in the
past, it'll probably continue to be there in the future. 2. Does it work? Depends on what you've done to the system previously. The stuff you like to has a fair amount of warning sprinkled over it. 3. Will RH support it? Nope. The admin I replaced at work tried this one from RHEL3 to RHEL4. He had issues with stock RHEL software. Nothing 3rd party, nothing fancy. The support rep told him that upgrades were not supported, and to back up his data and to try to duplicate the problem on a clean install. They would not assist once they determined the box had been upgraded.
You're both right. Software supports it. People won't.
And on CentOS the only people who matter are those who own the boxes. Let's not complicate their life.
John Summerfield wrote:
it might be point number 2
You may use Anaconda to perform a fresh installation of Red Hat Enterprise Linux 4.91 or to perform an upgrade from the latest updated version of Red Hat Enterprise Linux 4 to Red Hat Enterprise Linux 4.91.
beta stuff, we'll see when it comes around to release time - redhat have never yet, supported distro updates. Also, I am not sure what your fluff is about anyway ? People are creating and using hacked up redhat-release files all the time to suit apps like Oracle / db2 / clusterman etc...
I think reverting to yumconf is preferable; we're based off RHEL, so Fedora isn't especially relevant, and we're not supporting RHN so the RHN configuration files are irrelevant to us.
unless someone has some real reason for it, not going to happen. And to be honest, I've not seen any reason here.
Just you, making lots of noise.
If we ship a modified up2date that shares yum configuration, that's fine, our users don't want to talk to RHN anyway.
the up2date config's are also in centos-release. And i have no idea who you refer to when you say 'our users'.
OTOH RHEL users do want to use CentOS stuff sumetimes, and a yumconf package makes that easy.
most such people have custom yum config's anyway. Maybe we can put some details on a wiki page on howto get yum on rhel.
-------------------- Just to do a recap to make sure we all understand the position here.
There are 4 sorts of user cases, been addressed so far.
1. People on CentOS, using the default config's - well for them nothing changes, they carry on using stuff the way it works and thats that.
2. People with customised .repo files - again, since the .repo's are config files yum wont overwrite their customised version. but drop in .rpmnew and let user handle however they want to.
3. People who want to use centos's yum on other distro's - all they need to do is provide a rpm with their config's and have that rpm provide centos-release ( they dont want more than the config's since i presume they dont want the other payload from the real centos-release package, like /etc/issue and /etc/redhat-release ).
4. People using CentOS repo's from CentOS based projects ( smeserver, trixbox, openfiler etc ) - Well, Id think their project admins should be providing the right Provides: and config's in the first place. If any of them have issues, I'd be happy to work with them and resolve the issue om their platform.
did i miss someone ?
- K
John Summerfield wrote:
Eh? Doesn't Anaconda look at the release file to see what it's supposed to upgrade _from_? If it doesn't recognise it, how will it know how to upgrade?
you might want to read up on what anaconda is and when its used. you seem muchly confused here.
Karanbir Singh wrote:
John Summerfield wrote:
Eh? Doesn't Anaconda look at the release file to see what it's supposed to upgrade _from_? If it doesn't recognise it, how will it know how to upgrade?
you might want to read up on what anaconda is and when its used. you seem muchly confused here.
See function getRedHatReleaseString in /usr/lib/anaconda/partedUtils.py
It's looking at the release file, and the content matters.
I don't think I'm very confused at all.
(it happens I was looking in the general area for other reasons).
To override the contents of that, you specify "upgradeany" when booting.
Now, if people go creating their own centos-release package and changing the contents of that file (as they should), then they are inviting trouble.
John Summerfield wrote:
Karanbir Singh wrote:
John Summerfield wrote:
Eh? Doesn't Anaconda look at the release file to see what it's supposed to upgrade _from_? If it doesn't recognise it, how will it know how to upgrade?
you might want to read up on what anaconda is and when its used. you seem muchly confused here.
To override the contents of that, you specify "upgradeany" when booting.
Now, if people go creating their own centos-release package and changing the contents of that file (as they should), then they are inviting trouble.
no, not really - since upgradeany is the only way to get anaconda to move from el3 to el4 anyway and will, most likely, be the only way to move from el4 to el5.
with life-role relation of the enterprise class distro, few people actually move a machine from major release to major release - since its actually viable to let it just run ( look at all those C3 machines still out there )
Hi Johnny
As I said ... i can be easily convinced to to shift back, but shouldn't we try to do things like upstream?
We also use even multiple custom yum-repo packages (e.g. by logical location of the server) which conflicts/obsoletes the standard one. We don't had to track any centos-release changes, just have to build that package.
As most servers can't directly reach the public centos update servers, this update breaks further updates and we'd have to change centos-release (and track it for further changes) even we just want to use our own mirror.
So I'd very much like to get the old way back with a separate centos yumconf package.
Has anyone tried to add a %trigger section to the own package that disables the entries in the standard repo files? It should IMHO be possible to have that trigger being executed every time another package is installed or updated. But haven't tried yet.
Thanks a lot and kind regards
Roland
"Jim Perrin" jperrin@gmail.com wrote:
This also causes a related issue for RHEL users who want to use yum. In posts to the yum mailing list, it's often recommended that RHEL users grab yum from the centos repositories. As of the 4.4 release, they can no longer do this as yum requires yumconf, provided by centos-release, which will overwrite their /etc/redhat-release, and /etc/sysconfig/rhn/sources files among others. This either keeps them from using our yum packages, or forces them to migrate to centos which they may not be aware of if they install centos-release without thinking it through.
We've been using CentOS' yum on RHEL in conjunction with an empty RPM that provides yumconf. Having centos-release provide yumconf seems to complicate this without giving any particular advantage.
I see this as an interoperability issue, and it should be discussed a bit. I'm not convinced that a yumconf package is the way to go, but providing the files in centos-release doesn't seem to be the right way either. Other opinions?
I'd be happy to revert having a separate yumconf package, unless anyone has a better solution.
Ron
Ron Yorston wrote:
We've been using CentOS' yum on RHEL in conjunction with an empty RPM that provides yumconf. Having centos-release provide yumconf seems to complicate this without giving any particular advantage.
the advantage is better management ability on CentOS
I see this as an interoperability issue, and it should be discussed a bit. I'm not convinced that a yumconf package is the way to go, but providing the files in centos-release doesn't seem to be the right way either. Other opinions?
I'd be happy to revert having a separate yumconf package, unless anyone has a better solution.
use your own yum-conf.rpm that also provides a centos-release !
--- Karanbir Singh mail-lists@karan.org wrote:
Ron Yorston wrote:
We've been using CentOS' yum on RHEL in
conjunction with an empty RPM
that provides yumconf. Having centos-release
provide yumconf seems to
complicate this without giving any particular
advantage.
the advantage is better management ability on CentOS
Why is that?
if centos-release SPEC split the package, why any management ability is lost? you still will have one, and only one, SPEC file to manage. and, very likely, we all will be happy :-)
just my 2 cents cu roger
__________________________________________ RedHat Certified Engineer ( RHCE ) Cisco Certified Network Associate ( CCNA )
__________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Karanbir Singh wrote:
John Newbigin wrote:
I have a custom yumconf packages which prevents the centos version from installing the files in /etc/yum.repos.d/ but that is no longer effective.
Any ideas?
how about your own package provide a yumconf and a centos-release ? that way you can effectively lock out the Centos-distro-yum config's
Do you really want to tell people to fiddle with centos-release if all they want is no CentOS-Base.repo? Sounds like a support nightmare to me ...
Ralph
-
Gordon Rowell -
Jim Perrin -
John Newbigin -
John Summerfied -
John Summerfield
-
Johnny Hughes -
Karanbir Singh -
Matt Hyclak -
Michael Paesold -
Ralph Angenendt -
Roger Pe�a Escobio -
Roland Alder -
Ron Yorston -
seth vidal