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