Date: Mon, 12 Sep 2011 08:08:52 -0400 From: Ken Smith <kensmith@buffalo.edu> To: Alexandr Kovalenko <never@nevermind.kiev.ua> Cc: freebsd-hubs@freebsd.org Subject: Re: Change in layout / removal of older releases... Message-ID: <1315829332.40053.18.camel@bauer.cse.buffalo.edu> In-Reply-To: <CAJ2Kz1BL%2BTx5=mAhQvTDZ1VAQSXyz=OSKqXEuA9nyDQAoHwHQw@mail.gmail.com> References: <1314877232.69697.11.camel@bauer.cse.buffalo.edu> <CAJ2Kz1BL%2BTx5=mAhQvTDZ1VAQSXyz=OSKqXEuA9nyDQAoHwHQw@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
--=-rXSTjJ5Fzc8atPf2ciaX Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On Mon, 2011-09-12 at 13:16 +0300, Alexandr Kovalenko wrote: > On Thu, Sep 1, 2011 at 2:40 PM, Ken Smith <kensmith@buffalo.edu> wrote: >=20 > > 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. >=20 > Maybe it would be good idea to make symlinks in > FreeBSD/releases/amd64/ISO-IMAGES like >=20 > 9.0 -> FreeBSD/releases/amd64/amd64/ISO-IMAGES/9.0 >=20 > so people who tries to download ISO will find them in usual place? >=20 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. --=20 Ken Smith - From there to here, from here to | kensmith@buffalo.edu there, funny things are everywhere. | - Theodor Geisel | --=-rXSTjJ5Fzc8atPf2ciaX Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iEYEABECAAYFAk5t9kgACgkQ/G14VSmup/Y6lACcD44raeL6hgQwBehPY/RHnZwL gNwAoJjPFxPvzSV/kS/azGRQe1umnIJR =xh+C -----END PGP SIGNATURE----- --=-rXSTjJ5Fzc8atPf2ciaX--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1315829332.40053.18.camel>