<moved over from the CentOS list to CentOS-devel>
On Wed, 2006-11-22 at 01:06 +0000, Karanbir Singh wrote:
Matthew Miller wrote:
On Tue, Nov 21, 2006 at 06:32:29PM +0000, C. L. Martinez wrote:
Somebody knows if exists some roadmap about release beta process for CentOS 5 in parallell with RedHat ?? Or we need ot wait until RedHat 5 will be released??
I'm also curious if there's plans to do a separate Desktop and Server release. From what I saw in RHEL5 beta1, there's apparently a slightly different set of packages in each....
There is going to be a bit of a discussion on this soon, also howto manage the various repos within each tree.
- KB
There are differences in the upstream release for Client and Server (much like the difference between AS, ES, WS, Red Hat Desktop, etc). We handled this in CentOS-3 and CentOS-4 by just releasing the AS package set and it contains all the other subsets.
It is slightly different now, however, as there are separate yum repositories (and directories) for Server, Client, VM, Cluster*, etc. on the EL5 Beta2 CDs (much like CentOS has extras, centosplus, etc. :P).
In a yum tree on the server this is not too hard, links can be created to connect the packages that are the same and all can co-exist in one tree.
(that might also work OK for the Binary DVD too ... we might be able to fit all the packages on the DVD in separate repos/dirs and keep it under 4.3gb)
As far as I know, ln -s or hardlinks will not translate to size savings (or even work) on an iso9660 CD ... therefore it seems that we may have to either:
1. Combine all the packages into a single repository (CentOS or Release or Server, etc.) This is similar to what we currently do on 3 and 4 now, with all the AS packages included.
or
2. Release a CD set with Server and Client (and all the other repos on it ... showing everything) ... no idea how much space that takes yet or if it is doable. I would think (if we can't use links) that this set would be 6-9 discs in size.
or
3. Release a Client and Server CD, and a Client and Server DVD ... but put everything in one yum tree with a Client and Server and all the other dirs/repos under that tree. (I would imagine that each set would be 4-5 discs in size)
I think 3 is the way that makes the most sense ... it also requires the most disk space and bandwidth ... and requires the most maintenance. Option 1 is less disk space, in keeping with what we currently do, BUT creates an install that is not much like upstream.
Once installed, either of these methods becomes the same as all yum repos should be enabled by default, unless we have a centOS-release- client and centOS-release-server ... so that if you install client, you get only client repos by default and for server, only server repos by default .... and you could enable the others too manually on each if you want.
The developers need to play with all these ideas and test several things before we can even smartly discuss these options.
Once we have a better idea what this entails, we can discuss it further.
I'm sure Oracle is waiting on our decision, so we should make it soon :P
Thanks, Johnny Hughes
On Wed, 22 Nov 2006, Johnny Hughes wrote:
As far as I know, ln -s or hardlinks will not translate to size savings (or even work) on an iso9660 CD ... therefore it seems that we may have to either:
ISO9660 plus Rock Ridge extensions supports symbolic links. Some other distributions and systems (e.g. FreeBSD) use symbolic links on their installation CD's. So, that should not be a problem.
I'm sure Oracle is waiting on our decision, so we should make it soon :P
:).
-- Daniel
Johnny Hughes wrote:
<moved over from the CentOS list to CentOS-devel>
On Wed, 2006-11-22 at 01:06 +0000, Karanbir Singh wrote:
Matthew Miller wrote:
On Tue, Nov 21, 2006 at 06:32:29PM +0000, C. L. Martinez wrote:
Somebody knows if exists some roadmap about release beta process for CentOS 5 in parallell with RedHat ?? Or we need ot wait until RedHat 5 will be released??
I'm also curious if there's plans to do a separate Desktop and Server release. From what I saw in RHEL5 beta1, there's apparently a slightly different set of packages in each....
There is going to be a bit of a discussion on this soon, also howto manage the various repos within each tree.
- KB
There are differences in the upstream release for Client and Server (much like the difference between AS, ES, WS, Red Hat Desktop, etc). We handled this in CentOS-3 and CentOS-4 by just releasing the AS package set and it contains all the other subsets.
It is slightly different now, however, as there are separate yum repositories (and directories) for Server, Client, VM, Cluster*, etc. on the EL5 Beta2 CDs (much like CentOS has extras, centosplus, etc. :P).
In a yum tree on the server this is not too hard, links can be created to connect the packages that are the same and all can co-exist in one tree.
(that might also work OK for the Binary DVD too ... we might be able to fit all the packages on the DVD in separate repos/dirs and keep it under 4.3gb)
As far as I know, ln -s or hardlinks will not translate to size savings (or even work) on an iso9660 CD ... therefore it seems that we may have to either:
<snip>
Johnny,
from the man page of mkisofs it appears that mkisofs can detect hardlinks and realizes space savings based on these:
-cache-inodes Cache inode and device numbers to find hard links to files. If mkisofs finds a hard link (a file with multiple names), then the file will only appear once on the CD. This helps to save space on the CD. The option -cache-inodes is default on UNIX like operating systems. Be careful when using this option on a filesystem without unique inode numbers as it may result in files containing the wrong content on CD.
HTH, Kay
On Wed, 2006-11-22 at 15:12 +0100, Kay Diederichs wrote: <snip>
Johnny,
from the man page of mkisofs it appears that mkisofs can detect hardlinks and realizes space savings based on these:
-cache-inodes Cache inode and device numbers to find hard links to files. If mkisofs finds a hard link (a file with multiple names), then the file will only appear once on the CD. This helps to save space on the CD. The option -cache-inodes is default on UNIX like operating systems. Be careful when using this option on a filesystem without unique inode numbers as it may result in files containing the wrong content on CD.
That is what I get for thinking w/o a man page :P
Thanks to Kay and Daniel ... that makes this even more interesting :P
Thanks, Johnny Hughes
Folks,
Johnny,
from the man page of mkisofs it appears that mkisofs can detect hardlinks and realizes space savings based on these:
mkisofs (at least since version 1.13) does indeed detect hardlinks and stores a single copy of the data on the resulting ISO. I use it extensivelly and can attest to that.
Best regards,
On Wed, Nov 22, 2006 at 07:38:46AM -0600, Johnny Hughes wrote:
- Release a CD set with Server and Client (and all the other repos on
it ... showing everything) ... no idea how much space that takes yet or if it is doable. I would think (if we can't use links) that this set would be 6-9 discs in size.
This is the most like upstream, right?
The developers need to play with all these ideas and test several things before we can even smartly discuss these options.
Yeah. Particularly, the question is: is there any *real* distinction or problem with merging Desktop/Server together? Because doing it that way is almost certainly less work and bandwidth overall.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Ok, this kind of crazy stunt reminds me (a lot) from my time at Conectiva. So I might be able to contribute something, even if only some anedoctal facts.
On Wed, Nov 22, 2006 at 07:38:46AM -0600, Johnny Hughes wrote:
Somebody knows if exists some roadmap about release beta process for CentOS 5 in parallell with RedHat ?? Or we need ot wait until RedHat 5 will be released??
I'm also curious if there's plans to do a separate Desktop and Server release. From what I saw in RHEL5 beta1, there's apparently a slightly different set of packages in each....
There is going to be a bit of a discussion on this soon, also howto manage the various repos within each tree.
There are differences in the upstream release for Client and Server (much like the difference between AS, ES, WS, Red Hat Desktop, etc). We handled this in CentOS-3 and CentOS-4 by just releasing the AS package set and it contains all the other subsets.
It is slightly different now, however, as there are separate yum repositories (and directories) for Server, Client, VM, Cluster*, etc. on the EL5 Beta2 CDs (much like CentOS has extras, centosplus, etc. :P).
Once uppon a time ...
Conectiva loved to have everything splited. And I mean everything (glibc was like 50 packages, total). So we used to have some number of repositories. This eventually started reflecting the CD number too. Do CD1 was "main", CD2 was "extras". But "gnome" and "kde" were also on separate repositories.
This turned out to be a nightmare to maintain. I mean, some softwares would have a core package on the main (or extra) repositories, and one on the "kde" repository for the kde-ui, and one on the "gnome" repository for the gnome-ui.
Granularity is all very nice, but it can (and will) turn into a maintenance nightmare.
In a yum tree on the server this is not too hard, links can be created to connect the packages that are the same and all can co-exist in one tree.
(that might also work OK for the Binary DVD too ... we might be able to fit all the packages on the DVD in separate repos/dirs and keep it under 4.3gb)
As far as I know, ln -s or hardlinks will not translate to size savings (or even work) on an iso9660 CD ... therefore it seems that we may have to either:
- Combine all the packages into a single repository (CentOS or Release
or Server, etc.) This is similar to what we currently do on 3 and 4 now, with all the AS packages included.
Which is the best idea, as far as I'm concerned. We already have enough granunarity using yum groups.
- Release a CD set with Server and Client (and all the other repos on
it ... showing everything) ... no idea how much space that takes yet or if it is doable. I would think (if we can't use links) that this set would be 6-9 discs in size.
Unless you can make sure people can do an install (easily) with just a subset of those CDs, this is going to give you headaches, IMHO.
- Release a Client and Server CD, and a Client and Server DVD ... but
put everything in one yum tree with a Client and Server and all the other dirs/repos under that tree. (I would imagine that each set would be 4-5 discs in size)
This could work. The main advantage, the way I see it, is to keep it closer to the original upstram methodology.
I think 3 is the way that makes the most sense ... it also requires the most disk space and bandwidth ... and requires the most maintenance.
Actually, 2 will eventually require more maintenance.
Option 1 is less disk space, in keeping with what we currently do, BUT creates an install that is not much like upstream.
I don't think a problem there. The important thing is that it be "functionaly" identical to upstream. We are already using "yum", after all.
It might cause problem for people migrating from upstream to CentOS, thou.
Once installed, either of these methods becomes the same as all yum repos should be enabled by default, unless we have a centOS-release- client and centOS-release-server ... so that if you install client, you get only client repos by default and for server, only server repos by default .... and you could enable the others too manually on each if you want.
Maybe a yum plugin that reads /etc/sysconfig/install-mode, and so decide if we are running a server or client install (or custom, with everything enabled). Should be relatively easy to create, I suppose.
The developers need to play with all these ideas and test several things before we can even smartly discuss these options.
Once we have a better idea what this entails, we can discuss it further.
I also suggest the developers go and talk to people who worked on other distributions (talking old and current employees here). It might also give a nice perspective and the kind of maintenance traps you might find.
I'm pretty sure Acme and Cavassin(*) would be willing to help.
* - Both are former Conectiva owners and development directors, and were deeply involved on all these packaging decisions in the past. Johnny, if you want, contact me offlist and I'll give you their e-mail addresses. They both work at Mandriva now.
Best Regards,
- -- Rodrigo Barbosa "Quid quid Latine dictum sit, altum viditur" "Be excellent to each other ..." - Bill & Ted (Wyld Stallyns)
Rodrigo Barbosa wrote:
I'm pretty sure Acme and Cavassin(*) would be willing to help.
- Both are former Conectiva owners and development directors, and were
deeply involved on all these packaging decisions in the past. Johnny, if you want, contact me offlist and I'll give you their e-mail addresses. They both work at Mandriva now.
if they are interested, they should join the conversation here in the mailing list :)
- KB
-
Daniel de Kok -
Durval Menezes -
Johnny Hughes -
Karanbir Singh -
Kay Diederichs -
Matthew Miller -
Rodrigo Barbosa