Change in layout / removal of older releases...

[Ken Smith]

On Mon, 2011-09-12 at 13:16 +0300, Alexandr Kovalenko wrote:
> On Thu, Sep 1, 2011 at 2:40 PM, Ken Smith <kensmith at buffalo.edu> wrote:
> 
> > Support for 32-bit powerpc will be in:
> >
> >        .../releases/powerpc/powerpc
> >
> > while support for 64-bit powerpc will be in:
> >
> >        .../releases/powerpc/powerpc64
> >
> > when the shift is complete.  Note that this will only be for 9.X and
> > later branches.  When we do 8.3 it will use the old layout.
> 
> Maybe it would be good idea to make symlinks in
> FreeBSD/releases/amd64/ISO-IMAGES like
> 
> 9.0 -> FreeBSD/releases/amd64/amd64/ISO-IMAGES/9.0
> 
> so people who tries to download ISO will find them in usual place?
> 

We're still discussing what to do, there is no particularly good
answer to any of it.

For example here, what you suggest above works fine for amd64
but fails for powerpc.  The amd64 architecture under the new
scheme is known as "amd64-amd64" (`uname -m`-`uname -p`).  But
for powerpc as of 9.0 we have both 32-bit powerpc (powerpc-powerpc)
and 64-bit powerpc (powerpc-powerpc64).  So what should the symlink
in FreeBSD/releases/powerpc/ISO-IMAGES point to?

If you really want to shoe-horn the old directory layout into the
new directory layout you could say "use `uname -p` instead of
`uname -m` for where the symlinks in the old directory layout
go" (solving the powerpc issue mentioned above by creating
FreeBSD/releases/powerpc64/ISO-IMAGES).  But if pc98 comes
back for future releases (we're not doing pc98 builds for 9.0)
that causes problems because under the new naming scheme its
name is "pc98-i386".  Now go through the above exercise to see
where symlinks for it would need to go if we use `uname -p`.

Bottom line is that there is no good solution to backwards
compatibility based on anything sensible (using something
concrete like deciding on `uname -m` versus `uname -p`) for
the mapping once you start to factor in more than just the
set of architectures we are currently building.  Things like
having pc98 creep back in break anything we might put in place
now.  So it's possible we're just best off inflicting some pain
now to re-train people rather than put off the pain until some
seemingly arbitrary point in the future.  Now is when the
installer infrastructure is changing to rely on both the
hardware platform and processor architecture.  We could try to
put in compatibility symlinks as you suggest because the current
set of architectures can be shoe-horned into it by saying that
we're using `uname -p` to decide where to put the symlinks.
But then we're running the risk of that breaking due to us
picking up a new architecture (or having pc98 builds return
for 9.1, etc.) at some seemingly arbitrary point in the
future.

-- 
                                                Ken Smith
- From there to here, from here to      |       kensmith at buffalo.edu
  there, funny things are everywhere.   |
                      - Theodor Geisel  |
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: This is a digitally signed message part
Url : http://lists.freebsd.org/pipermail/freebsd-hubs/attachments/20110912/cad1e0d9/attachment.pgp