svn commit: r227536 - in head: release share/man/man7
Ken Smith
kensmith at buffalo.edu
Thu Nov 17 19:33:29 UTC 2011
On Thu, 2011-11-17 at 14:16 -0500, John Baldwin wrote:
> On Thursday, November 17, 2011 12:43:12 pm Ken Smith wrote:
> > On Thu, 2011-11-17 at 11:41 -0500, John Baldwin wrote:
> > > On Thursday, November 17, 2011 10:11:36 am Ken Smith wrote:
> > > > On Thu, 2011-11-17 at 14:57 +0000, Alexey Dokuchaev wrote:
> > > > > On Thu, Nov 17, 2011 at 09:44:52AM -0500, Ken Smith wrote:
> > > > > > This is the problem we are trying to "solve":
> > > > > >
> > > > > > Supported TARGET/TARGET_ARCH pairs for world and kernel targets
> > > > > > amd64/amd64
> > > > > > arm/arm
> > > > > > arm/armeb
> > > > > > i386/i386
> > > > > > ia64/ia64
> > > > > > mips/mipsel
> > > > > > mips/mipseb
> > > > > > mips/mips64el
> > > > > > mips/mips64eb
> > > > > > mips/mipsn32eb
> > > > > > pc98/i386
> > > > > > powerpc/powerpc
> > > > > > powerpc/powerpc64
> > > > > > sparc64/sparc64
> > > > >
> > > > > As I see it, for every pair except pc98/i386, second part should be
> used.
> > > > > For pc98/i386, first (pc98). Problem solved. ;-)
> > > > >
> > > > > ./danfe
> > > > >
> > > >
> > > > I'd still sort of prefer no special cases. However ...
> > > >
> > > > For the ISO / memstick filenames we could just program in `uname -p`
> > > > and ask the pc98 builder to modify the filenames post-build. But
> > > > we still have the dual names needed for the FTP site layout. There
> > > > it needs to be fully automated in the installer.
> > > >
> > > > So, given it seemed like we're sort of stuck with having the dual
> > > > names appearing in other places combined with it never causing us
> > > > to have special cases and/or conflicts it seemed like just biting
> > > > the bullet and having them in the ISO / memstick filenames too ...
> > > >
> > > > Have I mentioned I don't like any of the options? :-/
> > >
> > > I think collapsing down to one name if uname -m == uname -p is not that
> > > terrible and would preserve the existing layout for most of the current
> > > cases (only pc98 would change, yes)?
> > >
> >
> > If you're referring to the FTP directory tree layout we wind up with:
> >
> > .../releases/amd64/9.0-RELEASE
> > .../releases/amd64/ISO-IMAGES/9.0
> >
> > for an example of uname -m == uname -p. But for our two powerpc related
> > architectures we get:
> >
> > .../releases/powerpc/9.0-RELEASE
> > .../releases/powerpc/ISO-IMAGES/9.0
> > .../releases/powerpc/powerpc64/9.0-RELEASE
> > .../releases/powerpc/powerpc64/ISO-IMAGES/9.0
> >
> > I'm not sure I like the inconsistency.
>
> Given the available tradeoffs I prefer this to amd64/amd64. We could also
> define the rule another way, which is if a given TARGET only has a single
> TARGET_ARCH you just use TARGET, otherwise you use TARGET/TARGET_ARCH. (This
> can be parsed out of the output of 'make targets' fairly easily.) That would
> let you have:
>
> releases/amd64/9.0-RELEASE
> releases/powerpc/powerpc/9.0-RELEASE
> releases/powerpc/powerpc64/9.0-RELEASE
>
The code that would need to be fixed is in:
src/usr.sbin/bsdinstall/scripts/mirrorselect
which is running on the machine as it's being installed. I don't think
parsing the output of "make targets" in /usr/src is an option at that
point.
--
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/svn-src-all/attachments/20111117/e0e6be54/attachment.pgp
More information about the svn-src-all
mailing list