svn commit: r227536 - in head: release share/man/man7

[Ken Smith]

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.

Or were you referring to the ISO / memstick filenames?  If that's what
you were referring to then we get

	FreeBSD-9.0-RELEASE-amd64-bootonly.iso
	FreeBSD-9.0-RELEASE-powerpc-bootonly.iso
	FreeBSD-9.0-RELEASE-powerpc-powerpc64-bootonly.iso

If pc98 were being done we'd get

	.../releases/pc98/i386/9.0-RELEASE
	.../releases/pc98/i386/ISO-IMAGES/9.0
	FreeBSD-9.0-RELEASE-pc98-i386-bootonly.iso

I guess.  Was that the proposal?  Again I'm not fond of any of the
alternatives but if that's what we wind up with personally I'm more
in favor of "silly filenames" over needing to explain the
inconsistencies.

-- 
                                                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/e481babf/attachment.pgp