SCIENTIFIC-LINUX-DEVEL Archives

January 2007

SCIENTIFIC-LINUX-DEVEL@LISTSERV.FNAL.GOV

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
"Marc W. Mengel" <[log in to unmask]>
Reply To:
Marc W. Mengel
Date:
Tue, 2 Jan 2007 09:59:02 -0600
Content-Type:
text/plain
Parts/Attachments:
text/plain (62 lines)
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

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

ATOM RSS1 RSS2