I don't have a strong opinion but feel that the standard apt layout is
quite nice.

rpm http://$BASEURL <OS>/<ARCH> <STATUS>

The <OS> depends on the host operating system it can be sl3.0.5 or
sl4.4.0. The <ARCH> depends on the host hardware version it can be i386
or x86_64. The <STATUS> finally determines the version you will get.

I must support 3 platforms

this translates to a directory structure like

sl4.4.0/x86_64
sl4.4.0/x86_64/RPMS.unstable
sl4.4.0/x86_64/RPMS.unstable/headers
sl4.4.0/x86_64/RPMS.unstable/repodata
sl4.4.0/x86_64/SRPMS.unstable
sl4.4.0/x86_64/SRPMS.unstable/repodata
sl4.4.0/x86_64/SRPMS.testing
sl4.4.0/x86_64/SRPMS.testing/repodata
sl4.4.0/x86_64/RPMS.stable
sl4.4.0/x86_64/RPMS.stable/headers
sl4.4.0/x86_64/RPMS.stable/repodata
sl4.4.0/x86_64/SRPMS.stable
sl4.4.0/x86_64/SRPMS.stable/repodata
sl4.4.0/x86_64/base
sl4.4.0/x86_64/RPMS.testing
sl4.4.0/x86_64/RPMS.testing/headers
sl4.4.0/x86_64/RPMS.testing/repodata
sl4.4.0/x86_64/RPMS.tools
sl4.4.0/x86_64/RPMS.tools/headers
sl4.4.0/x86_64/RPMS.tools/repodata
sl4.4.0/x86_64/SRPMS.tools
sl4.4.0/x86_64/SRPMS.tools/repodata

and repeated for other OS's and architectures. So on test hosts I often
have an apt string as

rpm http://$BASEURL <OS>/<ARCH> stable testing tools

while developers have 

rpm http://$BASEURL <OS>/<ARCH> unstable tools

and production has 

rpm http://$BASEURL <OS>/<ARCH> stable

This may not be relevant to your discussion but its nice to see a
layout that makes <OS>/<ARCH>/<STATUS> distinctions in a clear
hierarchy. I don't see why you should not use the same hierarchy for
contrib and errata and updates as we use for stable, testing, unstable
and tools.

To me this is just cosmetic and I don't really care how its done as
long as its available I am bias to what ever causes you the least work,
and if you change things you will I assume document them, and make
hopefully make things simpler.

Regards

Owen







On Wed, 14 Mar 2007 09:27:34 -0500
Troy Dawson <[log in to unmask]> wrote:

> Marc W. Mengel wrote:
> > 
> >> Currently, SL 3.x and 4.x has the directory structure
> >>
> >> 4.4/i386/errata
> >> 4.4/i386/contrib
> >> 4.4/i386/SL/RPMS
> >>
> >> Where everything is pushed up into the arch directory.  CentOS has 
> >> things at
> >>
> >> 4.4/contrib/i386
> >> 4.4/updates/i386
> >> 4.4/os/i386/CentOS/RPMS
> >>
> > 
> > I think generally pushing the architecture type differences deeper (i.e. 
> > the CentOS layout) is easier to follow.  In fact, it would be, from that
> > perspective, nicer to do
> >   4.4/SL/RPMS/i386
> > but that's just me :-)
> > 
> > Marc
> I think that would require a whole rewrite of the installer.  The 
> installer needs it's supporting structure, so you put all that stuff 
> under /os/
> But I'll put you down as a vote of yes of the change for SL5
> 
> Troy
> -- 
> __________________________________________________
> Troy Dawson  [log in to unmask]  (630)840-6468
> Fermilab  ComputingDivision/LCSI/CSI DSS Group
> __________________________________________________