Sender: |
|
Date: |
Tue, 2 Jan 2007 09:03:06 -0600 |
MIME-version: |
1.0 |
Reply-To: |
|
Content-type: |
text/plain; format=flowed; charset=ISO-8859-1 |
Subject: |
|
From: |
|
Content-transfer-encoding: |
7BIT |
Comments: |
|
Parts/Attachments: |
|
|
Hello,
This currently is not set in stone, so now is the time to talk about it.
With RHEL5 beta2 Redhat has divided up their different products into
different repositories, each in it's own directory. So under
/rhel5/i386 you have the directories
Client Cluster ClusterStorage Server VT Workstation
This makes it easy for them to sell someone a package, they get a key,
and depending on what the key is, certain repositories are available.
But to distributions like us, well, it's not what we're used to.
Preliminary discussions on whiteboards between Connie and I have shown 3
ways that we can proceed. Each has it's Pro's and Con's.
1 - Do just what Red Hat does.
Directories:
/Client /Cluster /ClusterStorage /Server /VT /Workstation
Pro:
Just like RedHat
Con:
Duplication of pacakges in /Client and /Server
Hard for Users to find packages by hand
Hard for developers to figure out where to put packages
Why have them in separate directories when we will include them all
2 - Follow RedHat, but combine similar packages from Client and Server
Directories:
/ClientServer /Client /Cluster /ClusterStorage /Server /VT /Workstation
Pro:
Almost like RedHat
No duplication of packages
Con:
Hard for Users to find packages by hand
Hard for developers to figure out where to put packages
Why have them in separate directories when we will include them all
3 - Mush everything into our normal directory structure
Directories:
/SL /contrib /sites
Pro:
Easy for users to find packages
Easy for developers to know where to put packages
No duplication of packages
Makes more logical sense
Con:
Have to combine all the comps.xml files, each time we have a release
People used to regular RedHat might be a bit confused
Will require more anaconda changes
My personal opinion, and I'm willing to be disagreed with.
I want to go with option 3.
Troy
--
__________________________________________________
Troy Dawson [log in to unmask] (630)840-6468
Fermilab ComputingDivision/CSS CSI Group
__________________________________________________
|
|
|