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

 
> 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
> 

-- 
Stephan Wiesand
  DESY - DV -
  Platanenallee 6
  15738 Zeuthen, Germany