hi guys,
Something to talk about while we prep C-5 for release...
There were some packages that were updated along with release, I can imagine this was since the tree must have been frozen a while before actual release upstream. However, we dont have that problem - the tree hasent been released.
So, what does everyone thing ? Should we release the tree with the updates rolled in ? or should we release the tree exactly as upstream did, and also provide the updates to go alongside - but in the updates repo ?
One thing that I would be very hesitant to update would be the kernel, since updating that would imply updating the installer kernel as well. Which is going to cause lots of issues since its known that vendors and support people will ask for specific kernels at specific times ( eg. installed with x.y.z and 5.0.0 )
- KB
On 3/15/07, Karanbir Singh mail-lists@karan.org wrote:
hi guys,
Something to talk about while we prep C-5 for release...
There were some packages that were updated along with release, I can imagine this was since the tree must have been frozen a while before actual release upstream. However, we dont have that problem - the tree hasent been released.
So, what does everyone thing ? Should we release the tree with the updates rolled in ? or should we release the tree exactly as upstream did, and also provide the updates to go alongside - but in the updates repo ?
As a consumer of CentOS release's my point of view is that having it all rolled in as much as possible would be better. OTOH, I can see from your point of view that mimicking their tree religously would have some benefits too.
Cheers...james
----- "James Olin Oden" james.oden@gmail.com wrote:
On 3/15/07, Karanbir Singh mail-lists@karan.org wrote:
So, what does everyone thing ? Should we release the tree with the updates rolled in ? or should we release the tree exactly as
upstream
did, and also provide the updates to go alongside - but in the
updates
repo ?
As a consumer of CentOS release's my point of view is that having it all rolled in as much as possible would be better. OTOH, I can see from your point of view that mimicking their tree religously would have some benefits too.
Cheers...james
If the updates are rolled into the initial C5 release then we've lost all ability to ever do a base install that directly mimics the upstream release. For most folks that doesn't matter, but for some of us having that ability is pretty important. In a few weeks there'll be more updates anyway.
--- C. Halstead chris@sourcelabs.com SourceLabs - http://www.sourcelabs.com Dependable Open Source Systems
C. Halstead wrote:
----- "James Olin Oden" james.oden@gmail.com wrote:
On 3/15/07, Karanbir Singh mail-lists@karan.org wrote:
So, what does everyone thing ? Should we release the tree with the updates rolled in ? or should we release the tree exactly as
upstream
did, and also provide the updates to go alongside - but in the
updates
repo ?
As a consumer of CentOS release's my point of view is that having it all rolled in as much as possible would be better. OTOH, I can see from your point of view that mimicking their tree religously would have some benefits too.
Cheers...james
If the updates are rolled into the initial C5 release then we've lost all ability to ever do a base install that directly mimics the upstream release. For most folks that doesn't matter, but for some of us having that ability is pretty important. In a few weeks there'll be more updates anyway.
Maybe a copy of the outdated version could be archived somewhere for the unlikely event of someone ever wanting its unfixed bugs again - and the rest of us could have the spiffy new version as a default...
As for working with driver disks - the RHEL kernels are supposed to have stable binary driver interfaces for the life of the distribution. And if an update kernel doesn't work with a needed vendor driver, there wasn't much point in getting past the install anyway.
Les Mikesell wrote:
As for working with driver disks - the RHEL kernels are supposed to have stable binary driver interfaces for the life of the distribution. And if an update kernel doesn't work with a needed vendor driver, there wasn't much point in getting past the install anyway.
the problem with that is that lots of vendors ( Areca for example ) ship updated bits of various code and scripts in their DD's - which checks for the specific version of the running kernel and sometimes even other packages...
so while it works from this end, it does not work from all the other ends ( i suppose it does, but people are just checking for the wrong things before complaining that its not compatible )
James Olin Oden wrote:
On 3/15/07, Karanbir Singh mail-lists@karan.org wrote:
hi guys,
Something to talk about while we prep C-5 for release...
There were some packages that were updated along with release, I can imagine this was since the tree must have been frozen a while before actual release upstream. However, we dont have that problem - the tree hasent been released.
So, what does everyone thing ? Should we release the tree with the updates rolled in ? or should we release the tree exactly as upstream did, and also provide the updates to go alongside - but in the updates repo ?
As a consumer of CentOS release's my point of view is that having it all rolled in as much as possible would be better. OTOH, I can see from your point of view that mimicking their tree religously would have some benefits too.
I too would like them rolled in. If I userstand anaconda-list properly, it's now possible to include multiple repos in the install tree.
Why not add updates? In the CD images, it could be a separate CD so one could just download (or create) a refreshed CD image. Possibly, updates (U{1,2,3...} could be done this way too.
In the DVD image, it might be a separate directory tree that's simply replaced.
Also, pls look ar Jigdo (see Debian). It would allow users to Download master templates, and fill it in from a. Earlier ISOs b. One or more mirrors.
The final result is a bit-for-bit copy of the original, and jigdo checks the checksum.
To create U1 ISOs, folk could use jigdo to fetch the template, download (maybe from the local LAN if they've been downloaded wity yum and kept) all changes and create new images without downloading stuff they already have.
John Summerfield wrote:
I too would like them rolled in. If I userstand anaconda-list properly, it's now possible to include multiple repos in the install tree.
thats the main reason why we are considering so strongly to not roll them in, since its possible to enable the updates repo at install time and just use the packages from there instead of using the packages in the distro media....
Why not add updates? In the CD images, it could be a separate CD so one could just download (or create) a refreshed CD image. Possibly, updates (U{1,2,3...} could be done this way too.
Too much changes during an Quarterly Update cycle to go down that route - eg. by 5.5 you could end up with 12CD's or something like that - and the media needs to be rebuilt anyway ( the installer needs to know what rpms are available where before it starts doing its dep resolution )
Also, pls look ar Jigdo (see Debian). It would allow users to Download master templates, and fill it in from a. Earlier ISOs b. One or more mirrors.
The final result is a bit-for-bit copy of the original, and jigdo checks the checksum.
To create U1 ISOs, folk could use jigdo to fetch the template, download (maybe from the local LAN if they've been downloaded wity yum and kept) all changes and create new images without downloading stuff they already have.
doesnt Rsync already achieve much of this functionality ? when you rsync over an iso, you really should get only changed bits.
Having said that - if anyone wants to take up the jidgo distribution mechanism and work with us through release time doing whatever is required - please do feel free to step up and join the effort.
- KB
Karanbir Singh wrote:
John Summerfield wrote:
I too would like them rolled in. If I userstand anaconda-list properly, it's now possible to include multiple repos in the install tree.
thats the main reason why we are considering so strongly to not roll them in, since its possible to enable the updates repo at install time and just use the packages from there instead of using the packages in the distro media....
I'm thinking the updates should be in the install tree; if installing without an Internet connextion, they should still be available.
Why not add updates? In the CD images, it could be a separate CD so one could just download (or create) a refreshed CD image. Possibly, updates (U{1,2,3...} could be done this way too.
Too much changes during an Quarterly Update cycle to go down that route
- eg. by 5.5 you could end up with 12CD's or something like that - and
the media needs to be rebuilt anyway ( the installer needs to know what rpms are available where before it starts doing its dep resolution )
If all the current updates are on the one CD (would they fit), then many users can just refresh their updates repo and keep on with the same old six CDs. They could remaster a DVD simply by creating a new image with mkisofs and the other magic, including --graft-points.
Also, pls look ar Jigdo (see Debian). It would allow users to Download master templates, and fill it in from a. Earlier ISOs b. One or more mirrors.
The final result is a bit-for-bit copy of the original, and jigdo checks the checksum.
To create U1 ISOs, folk could use jigdo to fetch the template, download (maybe from the local LAN if they've been downloaded wity yum and kept) all changes and create new images without downloading stuff they already have.
doesnt Rsync already achieve much of this functionality ? when you rsync over an iso, you really should get only changed bits.
You are limited to where you get the updates from; only one source. Jigdo can, in principle, handle any number, including the previous image.
Having said that - if anyone wants to take up the jidgo distribution mechanism and work with us through release time doing whatever is required - please do feel free to step up and join the effort.
Has anyone got that magazine DVD (I think it was Linux Format) that has Jigdo set up so you can create CD images from the DVD?
- KB
Mostly, I'm too bandwidth-constrained (think dialup) to do much more than write emails.
On Thu, Mar 15, 2007 at 09:50:55PM +0000, Karanbir Singh enlightened us:
Something to talk about while we prep C-5 for release...
There were some packages that were updated along with release, I can imagine this was since the tree must have been frozen a while before actual release upstream. However, we dont have that problem - the tree hasent been released.
So, what does everyone thing ? Should we release the tree with the updates rolled in ? or should we release the tree exactly as upstream did, and also provide the updates to go alongside - but in the updates repo ?
One thing that I would be very hesitant to update would be the kernel, since updating that would imply updating the installer kernel as well. Which is going to cause lots of issues since its known that vendors and support people will ask for specific kernels at specific times ( eg. installed with x.y.z and 5.0.0 )
- KB
I vote we stick with upstream and just make the updates available immediately in the updates repo.
Matt
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Thu, Mar 15, 2007 at 05:54:52PM -0400, Matt Hyclak wrote:
On Thu, Mar 15, 2007 at 09:50:55PM +0000, Karanbir Singh enlightened us:
So, what does everyone thing ? Should we release the tree with the updates rolled in ? or should we release the tree exactly as upstream did, and also provide the updates to go alongside - but in the updates repo ?
I vote we stick with upstream and just make the updates available immediately in the updates repo.
Dito.
- -- Rodrigo Barbosa "Quid quid Latine dictum sit, altum viditur" "Be excellent to each other ..." - Bill & Ted (Wyld Stallyns)
On 3/15/07, Karanbir Singh mail-lists@karan.org wrote:
So, what does everyone thing ? Should we release the tree with the updates rolled in ? or should we release the tree exactly as upstream did, and also provide the updates to go alongside - but in the updates repo ?
One thing that I would be very hesitant to update would be the kernel, since updating that would imply updating the installer kernel as well. Which is going to cause lots of issues since its known that vendors and support people will ask for specific kernels at specific times ( eg. installed with x.y.z and 5.0.0 )
- KB
Well, I don't know much about this things, but I suggest rolling everything we can that doesn't impact too much on the installation (like the kernel). I don't know (if there are) other implications this might cause on depencies and how much this affect the installation environment.
Leonardo
Karanbir Singh wrote:
hi guys,
Something to talk about while we prep C-5 for release...
There were some packages that were updated along with release, I can imagine this was since the tree must have been frozen a while before actual release upstream. However, we dont have that problem - the tree hasent been released.
So, what does everyone thing ? Should we release the tree with the updates rolled in ? or should we release the tree exactly as upstream did, and also provide the updates to go alongside - but in the updates repo ?
One thing that I would be very hesitant to update would be the kernel, since updating that would imply updating the installer kernel as well. Which is going to cause lots of issues since its known that vendors and support people will ask for specific kernels at specific times ( eg. installed with x.y.z and 5.0.0 )
I agree for the last point : a lot of HW manufacturers release driver disks for a specific kernel (the one that will be used will always be the rhel one ..) so if you don't want to break driver disk compatibility (even if you can just edit the vermagic string in the module sitting on the driver disk ..) i'd prefer you stick with the upstream kernel version for the final release and put the newer one in the updates repo ... Imagine the numbers of question on #centos, on the forum and on the list if a driver disk doesn't work as expected ... and try to explain these guys that the main goal is to be 100% binary compatible ... :o) Just my opinion ...
Fabian Arrotin.
Karanbir Singh wrote:
hi guys,
Something to talk about while we prep C-5 for release...
There were some packages that were updated along with release, I can imagine this was since the tree must have been frozen a while before actual release upstream. However, we dont have that problem - the tree hasent been released.
So, what does everyone thing ? Should we release the tree with the updates rolled in ? or should we release the tree exactly as upstream did, and also provide the updates to go alongside - but in the updates repo ?
One thing that I would be very hesitant to update would be the kernel, since updating that would imply updating the installer kernel as well. Which is going to cause lots of issues since its known that vendors and support people will ask for specific kernels at specific times ( eg. installed with x.y.z and 5.0.0 )
- KB
One thing that has annoyed me in the past about RHEL/CentOS is that the installer often uses an old kernel that won't support some piece of hardware, when there is an update available that will support the hardware.
Perhaps there is a way to develop a "install with kernel x.y.z" or "grab latest kernel from repo" option in the bootloader or something for people who are running into issues with the default kernel? I know that's probably asking for a lot, but just a thought.
nethub@gmail.com wrote:
Perhaps there is a way to develop a "install with kernel x.y.z" or "grab latest kernel from repo" option in the bootloader or something for people who are running into issues with the default kernel? I know that's probably asking for a lot, but just a thought.
A new boot image would serve most people, probably everyone if it has the ability to change CD to get the installer off the original CD, for those who want to install from optical media.
nethub@gmail.com wrote:
One thing that has annoyed me in the past about RHEL/CentOS is that the installer often uses an old kernel that won't support some piece of hardware, when there is an update available that will support the hardware.
this isnt really related to the issue we were talking about here, try starting a new thread for new issues - it *really* goes a long way to maintain list sanity.
ok, now for your issue - the main thing here is that the initrd and the kernel module tree used during install time is semi-fixed based on rules and scripts included at the distro build time. So its non trivial changing that.
Perhaps there is a way to develop a "install with kernel x.y.z" or "grab latest kernel from repo" option in the bootloader or something for people who are running into issues with the default kernel? I know that's probably asking for a lot, but just a thought.
the ability to change the kernel you are installing with, is no trivial - however the ability to install an arbitrary kernel is possible with the centos-5 installer. Have you tested the beta installer as yet ?
Karanbir Singh wrote:
So, what does everyone thing ? Should we release the tree with the updates rolled in ? or should we release the tree exactly as upstream did, and also provide the updates to go alongside - but in the updates repo ?
Yes. Stick to upstream release disks and roll out the updates at the same time.
Ralph
Ralph Angenendt wrote:
Karanbir Singh wrote:
So, what does everyone thing ? Should we release the tree with the updates rolled in ? or should we release the tree exactly as upstream did, and also provide the updates to go alongside - but in the updates repo ?
Yes. Stick to upstream release disks and roll out the updates at the same time.
should we also add a line to the default installer that has the updates repo already listed ( but unselected ) at install time ? giving the user a chance to enable and use packages from there? ( only if they are really online )
- KB
On Fri, Mar 16, 2007 at 01:07:20AM +0000, Karanbir Singh enlightened us:
Ralph Angenendt wrote:
Karanbir Singh wrote:
So, what does everyone thing ? Should we release the tree with the updates rolled in ? or should we release the tree exactly as upstream did, and also provide the updates to go alongside - but in the updates repo ?
Yes. Stick to upstream release disks and roll out the updates at the same time.
should we also add a line to the default installer that has the updates repo already listed ( but unselected ) at install time ? giving the user a chance to enable and use packages from there? ( only if they are really online )
I think the update repo being there and unchecked by default is a great way to handle this.
Matt
Matt Hyclak wrote:
On Fri, Mar 16, 2007 at 01:07:20AM +0000, Karanbir Singh enlightened us:
Ralph Angenendt wrote:
Karanbir Singh wrote:
So, what does everyone thing ? Should we release the tree with the updates rolled in ? or should we release the tree exactly as upstream did, and also provide the updates to go alongside - but in the updates repo ?
Yes. Stick to upstream release disks and roll out the updates at the same time.
should we also add a line to the default installer that has the updates repo already listed ( but unselected ) at install time ? giving the user a chance to enable and use packages from there? ( only if they are really online )
I think the update repo being there and unchecked by default is a great way to handle this.
Just talking to Lance and Johnny online, and we feel the best way forward might be to add an Media-Updates/ repo on the iso's itself - then list both the local media updates as well as mirror.centos.org updates repo's in the anaconda screen, both disabled.
We feel this gives us the max wins in each direction ( but will slightly increase the data size on the last cd, as packages from cd-1 will move to cd-2 etc.
I will still try and ensure that a minimum install is possible using only cd-1, but cant promise that.
- KB
Karanbir Singh wrote:
Matt Hyclak wrote:
Just talking to Lance and Johnny online, and we feel the best way forward might be to add an Media-Updates/ repo on the iso's itself - then list both the local media updates as well as mirror.centos.org updates repo's in the anaconda screen, both disabled.
We feel this gives us the max wins in each direction ( but will slightly increase the data size on the last cd, as packages from cd-1 will move to cd-2 etc.
I will still try and ensure that a minimum install is possible using only cd-1, but cant promise that.
How would a kickstart user get the updates enabled?
I'm thinking the updates should be on one cd/dvd* by themselves, but obviously there should be a way to make Anaconda to look, and find out they're there. No problem for a network install, of course, there just needs to be a standard place for the updates.
Or USB disk or other location. 1 Gb flash drives are getting extremely cheap:-)
John Summerfield wrote:
How would a kickstart user get the updates enabled?
should be just as easy / hard as using any other repo at installtime.
I'm thinking the updates should be on one cd/dvd* by themselves,
they are only a few dozen MB's - would be a waste to have them on a new CD. But that can also be done, with a hook in firstboot that allows installing / upgrading from that.
- KB
Karanbir Singh wrote:
John Summerfield wrote:
How would a kickstart user get the updates enabled?
should be just as easy / hard as using any other repo at installtime.
I'm thinking the updates should be on one cd/dvd* by themselves,
they are only a few dozen MB's - would be a waste to have them on a new CD. But that can also be done, with a hook in firstboot that allows installing / upgrading from that.
Please check all my replies on the subject; the updates CD maybe can be rebuilt separately so users don't need to keep on downloading all the images as they get rebuilt for U1 etc.
Some enterprising souls could rebuild it weekly, and some vendors may well do that. Everythinglinux would be likely ro rebuild daily.
----- "Karanbir Singh" mail-lists@karan.org wrote:
Just talking to Lance and Johnny online, and we feel the best way forward might be to add an Media-Updates/ repo on the iso's itself - then list both the local media updates as well as mirror.centos.org updates repo's in the anaconda screen, both disabled.
We feel this gives us the max wins in each direction ( but will slightly increase the data size on the last cd, as packages from cd-1 will move to cd-2 etc.
I will still try and ensure that a minimum install is possible using only cd-1, but cant promise that.
- KB
+1 to this if we can still produce a single-CD minimal install. IMO the value if a one-disc install is higher than the value of a release that contains the initial update set. In a month or two there will be additional updates to apply anyway, so it doesn't seem prudent to sacrifice the one-disc install for the life of the release to gain a (very) small convenience up front. Just my .02
--- C. Halstead chris@sourcelabs.com SourceLabs - http://www.sourcelabs.com Dependable Open Source Systems
C. Halstead wrote:
----- "Karanbir Singh" mail-lists@karan.org wrote:
Just talking to Lance and Johnny online, and we feel the best way forward might be to add an Media-Updates/ repo on the iso's itself - then list both the local media updates as well as mirror.centos.org updates repo's in the anaconda screen, both disabled.
We feel this gives us the max wins in each direction ( but will slightly increase the data size on the last cd, as packages from cd-1 will move to cd-2 etc.
I will still try and ensure that a minimum install is possible using only cd-1, but cant promise that.
- KB
+1 to this if we can still produce a single-CD minimal install. IMO the value if a one-disc install is higher than the value of a release that contains the initial update set. In a month or two there will be additional updates to apply anyway, so it doesn't seem prudent to sacrifice the one-disc install for the life of the release to gain a (very) small convenience up front. Just my .02
if we can get a few more people voting this way, then I feel we have a decision on this issue.
- KB
Karanbir Singh spake the following on 3/16/2007 9:44 AM:
C. Halstead wrote:
----- "Karanbir Singh" mail-lists@karan.org wrote:
Just talking to Lance and Johnny online, and we feel the best way forward might be to add an Media-Updates/ repo on the iso's itself - then list both the local media updates as well as mirror.centos.org updates repo's in the anaconda screen, both disabled.
We feel this gives us the max wins in each direction ( but will slightly increase the data size on the last cd, as packages from cd-1 will move to cd-2 etc.
I will still try and ensure that a minimum install is possible using only cd-1, but cant promise that.
- KB
+1 to this if we can still produce a single-CD minimal install. IMO the value if a one-disc install is higher than the value of a release that contains the initial update set. In a month or two there will be additional updates to apply anyway, so it doesn't seem prudent to sacrifice the one-disc install for the life of the release to gain a (very) small convenience up front. Just my .02
if we can get a few more people voting this way, then I feel we have a decision on this issue.
- KB
I have to say that keeping as much upstream compatibility as possible is a good thing. Fixing the broken things is good, and I know that the CentOS team has probably fixed some bugs that upstream is appreciative of. But changing the release CD's might turn into a nightmare for the maintainers. Do you do it just for the initial release? How about for the next rollup? And after that, what?
If you see a critical bug that a package will fix, adding it would be a plus, as was the i586 installer you added. But keep the upstream compatibility where you can. It will make passing bug reports up the chain a little easier. "Even though you have to cook your own food, you are still eating at their table for free"
On Mar 16, 2007, at 12:44 PM, Karanbir Singh wrote:
C. Halstead wrote:
----- "Karanbir Singh" mail-lists@karan.org wrote:
Just talking to Lance and Johnny online, and we feel the best way forward might be to add an Media-Updates/ repo on the iso's itself - then list both the local media updates as well as mirror.centos.org updates repo's in the anaconda screen, both disabled.
We feel this gives us the max wins in each direction ( but will slightly increase the data size on the last cd, as packages from cd-1 will move to cd-2 etc.
I will still try and ensure that a minimum install is possible using only cd-1, but cant promise that.
- KB
+1 to this if we can still produce a single-CD minimal install. IMO the value if a one-disc install is higher than the value of a release that contains the initial update set. In a month or two there will be additional updates to apply anyway, so it doesn't seem prudent to sacrifice the one-disc install for the life of the release to gain a (very) small convenience up front. Just my .02
if we can get a few more people voting this way, then I feel we have a decision on this issue.
- KB
I am agreeable to this, but I would actually prefer to simply mimic upstream -- release 5.0 with the same base pacakges as upstream, and provide necessary updates in the updates repo. I don't see a strong reason to spend time modifying the CD images to contain a few package updates that are easily downloaded after install time.
If you proceed with the suggestion you mentioned above, are you implying that the so called "zero day updates" will appear in both the "media-updates" repo on the CD, and in the official updates repo on the FTP & mirrors?
-Jeff
Jeff Sheltren wrote:
On Mar 16, 2007, at 12:44 PM, Karanbir Singh wrote:
C. Halstead wrote:
----- "Karanbir Singh" mail-lists@karan.org wrote:
Just talking to Lance and Johnny online, and we feel the best way forward might be to add an Media-Updates/ repo on the iso's itself - then list both the local media updates as well as mirror.centos.org updates repo's in the anaconda screen, both disabled.
We feel this gives us the max wins in each direction ( but will slightly increase the data size on the last cd, as packages from cd-1 will move to cd-2 etc.
I will still try and ensure that a minimum install is possible using only cd-1, but cant promise that.
- KB
+1 to this if we can still produce a single-CD minimal install. IMO the value if a one-disc install is higher than the value of a release that contains the initial update set. In a month or two there will be additional updates to apply anyway, so it doesn't seem prudent to sacrifice the one-disc install for the life of the release to gain a (very) small convenience up front. Just my .02
if we can get a few more people voting this way, then I feel we have a decision on this issue.
- KB
I am agreeable to this, but I would actually prefer to simply mimic upstream -- release 5.0 with the same base pacakges as upstream, and provide necessary updates in the updates repo. I don't see a strong reason to spend time modifying the CD images to contain a few package updates that are easily downloaded after install time.
"easily downloaded?"
How long since you lived with this? I don't have a choice! [summer@bilby ~]$ ping -c5 -q beta.centos.org ping: unknown host beta.centos.org [summer@bilby ~]$ ping -c5 -q beta.centos.org PING beta.centos.org (72.13.100.148) 56(84) bytes of data.
--- beta.centos.org ping statistics --- 5 packets transmitted, 4 received, 20% packet loss, time 13070ms rtt min/avg/max/mdev = 1073.620/1254.659/1491.147/184.761 ms, pipe 3 [summer@bilby ~]$ [summer@bilby ~]$
some of my systems rarely get software updates because it's too difficult. Software updates are rarely accessible when I install.
If you proceed with the suggestion you mentioned above, are you implying that the so called "zero day updates" will appear in both the "media-updates" repo on the CD, and in the official updates repo on the FTP & mirrors?
-Jeff _______________________________________________ CentOS-devel mailing list CentOS-devel@centos.org http://lists.centos.org/mailman/listinfo/centos-devel
On Mar 16, 2007, at 4:01 PM, John Summerfield wrote:
Jeff Sheltren wrote:
I am agreeable to this, but I would actually prefer to simply mimic upstream -- release 5.0 with the same base pacakges as upstream, and provide necessary updates in the updates repo. I don't see a strong reason to spend time modifying the CD images to contain a few package updates that are easily downloaded after install time.
"easily downloaded?"
How long since you lived with this? I don't have a choice! [summer@bilby ~]$ ping -c5 -q beta.centos.org ping: unknown host beta.centos.org [summer@bilby ~]$ ping -c5 -q beta.centos.org PING beta.centos.org (72.13.100.148) 56(84) bytes of data.
--- beta.centos.org ping statistics --- 5 packets transmitted, 4 received, 20% packet loss, time 13070ms rtt min/avg/max/mdev = 1073.620/1254.659/1491.147/184.761 ms, pipe 3
Well, actually my Internet connection at home as been down for a week now - yay lazy Caribbean islands!
But back on topic, if connectivity to mirrors is such a big issue, why not mirror the needed packages while you are online and then point your machines to a local mirror?
It is not like these packages will not be available when CentOS 5 goes public, ti's just a matter of if they'll be on the CD or not. In my opinion, it's not worth the trouble to modify the CDs and installer, but I'm not the one doing the work, so I'll leave that decision up to the centos developers.
-Jeff
Jeff Sheltren wrote:
On Mar 16, 2007, at 4:01 PM, John Summerfield wrote:
Jeff Sheltren wrote:
I am agreeable to this, but I would actually prefer to simply mimic upstream -- release 5.0 with the same base pacakges as upstream, and provide necessary updates in the updates repo. I don't see a strong reason to spend time modifying the CD images to contain a few package updates that are easily downloaded after install time.
"easily downloaded?"
How long since you lived with this? I don't have a choice! [summer@bilby ~]$ ping -c5 -q beta.centos.org ping: unknown host beta.centos.org [summer@bilby ~]$ ping -c5 -q beta.centos.org PING beta.centos.org (72.13.100.148) 56(84) bytes of data.
--- beta.centos.org ping statistics --- 5 packets transmitted, 4 received, 20% packet loss, time 13070ms rtt min/avg/max/mdev = 1073.620/1254.659/1491.147/184.761 ms, pipe 3
Well, actually my Internet connection at home as been down for a week now - yay lazy Caribbean islands!
But back on topic, if connectivity to mirrors is such a big issue, why not mirror the needed packages while you are online and then point your machines to a local mirror?
Through a modem?
It is not like these packages will not be available when CentOS 5 goes public, ti's just a matter of if they'll be on the CD or not. In my opinion, it's not worth the trouble to modify the CDs and installer, but I'm not the one doing the work, so I'll leave that decision up to the centos developers.
_I_ can download the ISOs at work, but not everyone is even that well-placed. Keeping up2date is a lot more bother. Laptops, nt so bad, but non-portables? My WBEL system hasn't been updated.
John Summerfield wrote:
It is not like these packages will not be available when CentOS 5 goes public, ti's just a matter of if they'll be on the CD or not. In my opinion, it's not worth the trouble to modify the CDs and installer, but I'm not the one doing the work, so I'll leave that decision up to the centos developers.
_I_ can download the ISOs at work, but not everyone is even that well-placed. Keeping up2date is a lot more bother. Laptops, nt so bad, but non-portables? My WBEL system hasn't been updated.
OK, so at this point what is the difference of having 5-10 updated packages at release time?
-Jeff
--- Karanbir Singh mail-lists@karan.org wrote:
C. Halstead wrote:
----- "Karanbir Singh" mail-lists@karan.org
wrote:
Just talking to Lance and Johnny online, and we
feel the best way
forward might be to add an Media-Updates/ repo on
the iso's itself -
then list both the local media updates as well as
mirror.centos.org
updates repo's in the anaconda screen, both
disabled.
We feel this gives us the max wins in each
direction ( but will
slightly increase the data size on the last cd,
as packages from cd-1
will move to cd-2 etc.
I will still try and ensure that a minimum
install is possible using
only cd-1, but cant promise that.
- KB
+1 to this if we can still produce a single-CD
minimal install. IMO the value if a one-disc install is higher than the value of a release that contains the initial update set. In a month or two there will be additional updates to apply anyway, so it doesn't seem prudent to sacrifice the one-disc install for the life of the release to gain a (very) small convenience up front. Just my .02
if we can get a few more people voting this way, then I feel we have a decision on this issue.
I also vote for follow RH
the new kernel I think will not give any plus hardware support only security fix, so why not to install it inmidiatly after os instalation ...
cu roger
__________________________________________ RedHat Certified Engineer ( RHCE ) Cisco Certified Network Associate ( CCNA )
____________________________________________________________________________________ Don't get soaked. Take a quick peek at the forecast with the Yahoo! Search weather shortcut. http://tools.search.yahoo.com/shortcuts/#loc_weather
single disc minimal install following the upstream's release +1
Karanbir Singh wrote:
C. Halstead wrote:
----- "Karanbir Singh" mail-lists@karan.org wrote:
Just talking to Lance and Johnny online, and we feel the best way forward might be to add an Media-Updates/ repo on the iso's itself - then list both the local media updates as well as mirror.centos.org updates repo's in the anaconda screen, both disabled.
We feel this gives us the max wins in each direction ( but will slightly increase the data size on the last cd, as packages from cd-1 will move to cd-2 etc.
I will still try and ensure that a minimum install is possible using only cd-1, but cant promise that.
- KB
+1 to this if we can still produce a single-CD minimal install. IMO the value if a one-disc install is higher than the value of a release that contains the initial update set. In a month or two there will be additional updates to apply anyway, so it doesn't seem prudent to sacrifice the one-disc install for the life of the release to gain a (very) small convenience up front. Just my .02
if we can get a few more people voting this way, then I feel we have a decision on this issue.
- KB
On 3/16/07, C. Halstead chris@sourcelabs.com wrote:
+1 to this if we can still produce a single-CD minimal install. IMO the value if a one-disc install is higher than the value of a release that contains the initial update set. In a month or two there will be additional updates to apply anyway, so it doesn't seem prudent to sacrifice the one-disc install for the life of the release to gain a (very) small convenience up front. Just my .02
Can I change my vote to this one?
Matt Hyclak wrote:
should we also add a line to the default installer that has the updates repo already listed ( but unselected ) at install time ? giving the user a chance to enable and use packages from there? ( only if they are really online )
I think the update repo being there and unchecked by default is a great way to handle this.
Better, there (on the media if possible) and checked if it is immediately available, but don't spend five minutes finding out. I hate it when I configure an ntp server (pool.ntp.org) and then the box spends ages trying to access the servers when there's no Internet connectivity.
On Fri, 2007-03-16 at 01:07 +0000, Karanbir Singh wrote:
Ralph Angenendt wrote:
Karanbir Singh wrote:
So, what does everyone thing ? Should we release the tree with the updates rolled in ? or should we release the tree exactly as upstream did, and also provide the updates to go alongside - but in the updates repo ?
Yes. Stick to upstream release disks and roll out the updates at the same time.
should we also add a line to the default installer that has the updates repo already listed ( but unselected ) at install time ? giving the user a chance to enable and use packages from there? ( only if they are really online )
+1 good idea!
Paul
Cent has always mimicked the upstream...why go away from the model that has made this distro the premier free enterprise distro?
Karanbir Singh wrote:
hi guys,
Something to talk about while we prep C-5 for release...
There were some packages that were updated along with release, I can imagine this was since the tree must have been frozen a while before actual release upstream. However, we dont have that problem - the tree hasent been released.
So, what does everyone thing ? Should we release the tree with the updates rolled in ? or should we release the tree exactly as upstream did, and also provide the updates to go alongside - but in the updates repo ?
One thing that I would be very hesitant to update would be the kernel, since updating that would imply updating the installer kernel as well. Which is going to cause lots of issues since its known that vendors and support people will ask for specific kernels at specific times ( eg. installed with x.y.z and 5.0.0 )
- KB
William Warren wrote:
Cent has always mimicked the upstream...why go away from the model that has made this distro the premier free enterprise distro?
Mimic, but not follow religiously. Until now, RHEL has used up2date, CentOS has preferred yum. Improvements that don't impair compatibility should be welcomed.
I recommend including all available updates including the kernel.
Regarding the kernel and hardware requiring a driver disk. Either the driver will still be ABI compatible with any new kernel installed at 'run time' - or - the driver is not compatible and a new driver is required regardless.
The only issue to investigate is any artificial restrictions on driver disks imposed by anaconda.
I have not used a driver disk since RHEL7.2 so I don't know what issues might lie there.
John.
Karanbir Singh wrote:
hi guys,
Something to talk about while we prep C-5 for release...
There were some packages that were updated along with release, I can imagine this was since the tree must have been frozen a while before actual release upstream. However, we dont have that problem - the tree hasent been released.
So, what does everyone thing ? Should we release the tree with the updates rolled in ? or should we release the tree exactly as upstream did, and also provide the updates to go alongside - but in the updates repo ?
One thing that I would be very hesitant to update would be the kernel, since updating that would imply updating the installer kernel as well. Which is going to cause lots of issues since its known that vendors and support people will ask for specific kernels at specific times ( eg. installed with x.y.z and 5.0.0 )
- KB
John Newbigin wrote:
I recommend including all available updates including the kernel.
Regarding the kernel and hardware requiring a driver disk. Either the driver will still be ABI compatible with any new kernel installed at 'run time' - or - the driver is not compatible and a new driver is required regardless.
The only issue to investigate is any artificial restrictions on driver disks imposed by anaconda.
I have not used a driver disk since RHEL7.2 so I don't know what issues might lie there.
most DD's check for a specific kernel version, i think its going to be a while before the whole kernel-abi / whitelisting / updagrate route for DD's becomes mainstream - till such time, imho we should stick with release kernels for iso spins.
- KB
-
C. Halstead -
Fabian Arrotin -
James Olin Oden -
Jeff Sheltren -
John Newbigin -
John Summerfield -
Karanbir Singh -
Leonardo Pinheiro -
Leonardo Vilela Pinheiro
-
Les Mikesell -
Matt Hyclak -
nethub＠gmail.com -
Paul -
Ralph Angenendt -
Rodrigo Barbosa -
Roger Peña -
Scott Silva -
William Warren