On 01/17/2016 10:53 AM, Mike Frysinger wrote:
> sure, but you said "should we not remove support for sparcv8 and
> older". you can't drop support for them w/out breaking the
> embedded/cross case.
I guess what i meant was don't release stage3's and ISO's for older
archs, but in reality we are already doing that as the current SPARC
port requires sparcv9 because of the kernel.
> correct, but we don't support this case with any other arch. you don't
> do migration between them, you pick during initial download. this is
> why we have x86 & amd64 stage3 tarballs, s390 & s390x tarballs, ppc &
> ppc64 stage tarballs. we'd simply have sparc & sparc64 state3 tarballs.
> here's where naming gets tricky. we do not want a new KEYWORD. i think
> ppc/ppc64 was a mistake. we don't have mips/mips64 (and mipsn32) and
> they've been fine. same for amd64 & x32. i.e. we just treat it as a
> new ABI. as for profiles, we can create new subdirs under sparc where
> it makes sense. so we'd take all the sparc32-specific stuff out and
> move it to a new subdir, and create a sparc64 subdir to hold the new
> specific bits. profiles/arch/sparc/ - common stuff here sparc32/ -
> sparc32 stuff here sparc64/ - sparc64 stuff here
> profiles/default/linux/sparc/ - common stuff here sparc32/ - sparc32
> stuff here sparc64/ - sparc64 stuff here any time a package needs to
> change its behavior based on 32-bit/64-bit, it should be doing compile
> time tests.
That's an interesting viewpoint and adding a keyword generally creates
more work for everyone. In the case of a single sparc profile with
various 32bit / 64bit sub-profiles how do you handle the case of an
application that requires 32bit and only 32bit? Wine would be a good
example. On x86 we have use flags and a use expand for ABI_X86, and wine
consumes that flag. However, we don't have those flags on SPARC. So
portage is going to use whatever the ABI variable is set to regardless
of whether it will work or not.
I am told SILO will only run in a 32bit env, but ill cross that bridge
when i get there. But having a use flag for 32bit would make crossing
that bridge easier to cross. Or maybe theres a better way than how AMD64
/ X86 does it?
> yes, it seems like interest has waned in the sparc port. if you want to
> start picking this up, i'm sure no one would mind.
>
> if you're having trouble getting through the recruitment process, cc me
> on the e-mails & bugs, and i can be your mentor.
>
> as for the general sparc work, sign up for the sparc mailing list by
> sending a blank e-mail to gentoo-sparc+subscribe@lists.gentoo.org.
> then start posting your work/ideas/patches/etc... to that list. we
> can use that to discuss any other stuff you want. we probably should
> move the profile talk/etc... from above there too.
>
> on a semi-related note, you don't happen to live in or near Los Angeles
> CA ? there's a conference this next weekend (Jan 22 - Jan 24) that you
> could stop by and we could chat in person.
> -mike
Yes, i am already subscribed there. I'll CC that list so we can get some
record of all of this. Unfortunately i am on the opposite side of the
country (Ohio), so probably not. I would consider future events though
given proper time to plan and such.
> sure, but you said "should we not remove support for sparcv8 and
> older". you can't drop support for them w/out breaking the
> embedded/cross case.
I guess what i meant was don't release stage3's and ISO's for older
archs, but in reality we are already doing that as the current SPARC
port requires sparcv9 because of the kernel.
> correct, but we don't support this case with any other arch. you don't
> do migration between them, you pick during initial download. this is
> why we have x86 & amd64 stage3 tarballs, s390 & s390x tarballs, ppc &
> ppc64 stage tarballs. we'd simply have sparc & sparc64 state3 tarballs.
> here's where naming gets tricky. we do not want a new KEYWORD. i think
> ppc/ppc64 was a mistake. we don't have mips/mips64 (and mipsn32) and
> they've been fine. same for amd64 & x32. i.e. we just treat it as a
> new ABI. as for profiles, we can create new subdirs under sparc where
> it makes sense. so we'd take all the sparc32-specific stuff out and
> move it to a new subdir, and create a sparc64 subdir to hold the new
> specific bits. profiles/arch/sparc/ - common stuff here sparc32/ -
> sparc32 stuff here sparc64/ - sparc64 stuff here
> profiles/default/linux/sparc/ - common stuff here sparc32/ - sparc32
> stuff here sparc64/ - sparc64 stuff here any time a package needs to
> change its behavior based on 32-bit/64-bit, it should be doing compile
> time tests.
That's an interesting viewpoint and adding a keyword generally creates
more work for everyone. In the case of a single sparc profile with
various 32bit / 64bit sub-profiles how do you handle the case of an
application that requires 32bit and only 32bit? Wine would be a good
example. On x86 we have use flags and a use expand for ABI_X86, and wine
consumes that flag. However, we don't have those flags on SPARC. So
portage is going to use whatever the ABI variable is set to regardless
of whether it will work or not.
I am told SILO will only run in a 32bit env, but ill cross that bridge
when i get there. But having a use flag for 32bit would make crossing
that bridge easier to cross. Or maybe theres a better way than how AMD64
/ X86 does it?
> yes, it seems like interest has waned in the sparc port. if you want to
> start picking this up, i'm sure no one would mind.
>
> if you're having trouble getting through the recruitment process, cc me
> on the e-mails & bugs, and i can be your mentor.
>
> as for the general sparc work, sign up for the sparc mailing list by
> sending a blank e-mail to gentoo-sparc+subscribe@lists.gentoo.org.
> then start posting your work/ideas/patches/etc... to that list. we
> can use that to discuss any other stuff you want. we probably should
> move the profile talk/etc... from above there too.
>
> on a semi-related note, you don't happen to live in or near Los Angeles
> CA ? there's a conference this next weekend (Jan 22 - Jan 24) that you
> could stop by and we could chat in person.
> -mike
Yes, i am already subscribed there. I'll CC that list so we can get some
record of all of this. Unfortunately i am on the opposite side of the
country (Ohio), so probably not. I would consider future events though
given proper time to plan and such.