Stephan Wiesand wrote:
> On Tue, 2 Jan 2007, Marc W. Mengel wrote:
> 
>> Howabout we do 3, and add some symlinks, ClientServer Client, etc. that all
>> point to the common directory, so things that are *looking* for
>> the RedHat-style path will find them, but everyone else can ignore them...
>>
>> Marc
> 
> Just in case it wasn't obvious from my reply to the alpha anouncement: I'm 
> very much in favour of 3.
> 
> The links Marc proposes may help in some cases, and are simple enough to 
> provide. I'm just not 100.00% sure they'd never cause any problem. Like 
> if it turns out the /Client etc. will become necessary - say, because TUV 
> starts shipping different kernels for Client and Server with Update 2. Or 
> for installations with or without the "Virtualization Option" purchased.
> Of course that would throw up problems much harder to deal with than 
> repository structure and existing symlinks that would have to be replaced
> by true directories.
> 
> Next on my list would be option 1. Ugly, and the split would be of no use  
> to SL, but it has the least potential for surprise. But see above: In all
> cases I can actually imagine where we'd be longing for having gone with 
> this one, that won't be of much help unless the whole distribution - and not 
> just the repository - is split the same way as the upstream one. And I 
> guess (hope) that's not being discussed today?
> 
> Option 2 is least appealing to me. If the structure is changed at 
> all, why not go all the way and collapse everything into SL/RPMS.
> 
>   Stephan
> 

Hi Stephan,
You brought up a good senario, about the different kernels for Client 
and Server.  The reason it's a good scenario is because it's already there.
There is a different kernel in VT.  Whenever you pick virtulization, you 
get *only* the xen kernel.  I believe this is because yum is looking for 
a kernel, and the xen kernel wins.
This might be fine for a good majority of people, but I'm sure there are 
going to be some who really don't want the virtual kernel.  And if we 
squish them all together ... well, there is only going to be one kernel, 
xen.
So, even if we squish things together, we need to think of what to do 
with those packages that overlap, that a user may or may not want.

Troy

>  
>> Troy Dawson wrote:
>>> 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
__________________________________________________