Nekochan Net

Anyone else think that standardizing on /usr/neko before things get too far down the road would be a good idea ?

how about /NEKOCHAN

_________________
The preceding thoughts were brought to you by Jack Daniels.

Hello,

No matter the place until it is standard and not in /usr/local:-)
But that should be a good idea to standardize the naming,the location,the content of packages,the mips3/mips4 n32 an use lib32 for n32.

So ?

@+

LoWeN

_________________
UX powered

You guys know what you're doing - I just want it all in one place and like the way neko gets well-deserved credit.

i agree here. /usr/local is just idiotic as the chance for overwriting or being overwritten is almost 100% guaranteed.

/usr/neko or /opt/neko would be my choice

cheers.

_________________
The preceding thoughts were brought to you by Jack Daniels.

Okay. I hate to be a pushy bastard (yeah, right) but ...

First a big thanks to squeen and semifly for creating the nekoware concept with their huge Christmas present. Without their initial effort people would probably still be just *talking* about replacing the moribund freeware.sgi.com.

Second and with the permission of Neko himself, wouldn't it make sense to create a set of qualifications for "nekoware" ? This shouldn't discourage people from contributing other software, but should be an additional category, imo. To qualify as nekoware, the program should

live in a standard location
follow some guidelines, such as having a readme describing the dependencies and other minor requirements:-)
perhaps a gcc stream and a MipsPro stream ?
perhaps also add a Nekoware page to the Icon Catalog and drop an icon in there ?
whatever else more experienced people than I think ...

but imo again, organizing the *beginning* of a project such as this does a hell of a lot to make life easier, smoother, and more comfortable down the road. The sooner some guidelines are agreed upon, the sooner what *could* be the best thing to happen to hobbiest Irixware in ages can get up to speed.

And once again, squeen and semifly - and others too, esp foetz and whiter and dexter et al - you guys do a heck of a job. Duo xie ...

That's in the works, however this is a community effort and getting everybodys ideas sorted takes time. People are still debating over basics principicles (compiler, target directory, binary etc) but I'm sure that'll a set of "official qualifications" will be released at some point.

_________________
configure complete, now type 'make' and pray.

I argued for /usr/local in the past as it makes porting some packages with broken configure script easier, although there is a risk that your installation can get trampled.
However, I'll go along with /usr/neko or /opt/neko if others wish to go down that route, as it is a neater solution and it publicises the site and its creator.

If I come accross a broken configure setup I guess I'll just have to be a bit less lazy and actually fix it.

Having said that, one thing I am not too keen on having lib32 directory within this structure. Let's just keep it simple and have a lib directory. No one here is creating binaries in O32 format, so why complicate things.
lib and lib32 only exist within SGI's system libs (and freeware) due to need to support legacy software. We don't have to.

Nik.

ok...
switching to /opt/neko sounds fine to me (using /usr gives me the shivers) and after giving the lib32 dir some thought ... hm.... I build everything in lib32 but what the hell. If we stick to n32 only, then it'll be fine to me.

And for some reason I feel like using /opt/nekopro for mipspro based builds :) But not sure about that though. Depends on if people want to stick to gccrap or not. (preferably not)

_________________
Shall I describe it to you? Or do you want me to get you a box?

Hi,

what about using lib32 and generating a link from lib to lib32 ? There may be special cases with 64bit versions ?

Regards

Matthias

_________________
Life is what happens while we are making other plans

that link will be of no use since the location of the library files is hardcoded. They expect to be in the location they were first installed to.

If we decide to only build n32 as official 'nekoware' then just a lib dir sounds fine. But if we decide that 64 also should be regarded as 'nekoware' then we should stick to the lib/lib32/lib64 dir structure.

I vote for the first option regarding to 'nekoware'. Non-neko software can ofcourse use its own structure, but that's out of this scope and should not go into the /opt/neko dir at all anyway.

_________________
Shall I describe it to you? Or do you want me to get you a box?

i think we need to vote from all the current developers for future placement of the software packages. but we also have to address the following issues:

1) Which environment (6.5.22 or lower or higher, maintenance or feature stream)
2) Which compiler (mipspro 7.3.1.3, mipspro 7.41 or even gcc 3.x)
3) Which ABI? either mips3, mips4 or both.

...which will determine the placement and naming as well

or /lib and /lib64 would work ... 64-bit would be pretty unusual, I think. 'Specially since in real life it's actually *slower* than 32-bit.

that sounds like a good idea, too. /opt/neko for gcc and /opt/nekopro for MipsPro ? Easy to distinguish between them, clean, elegant ... nice. Mikey likes it.

My toughts:

1) whatever env is available for free from support.sgi.com (6.5.20m i think) it would be best. If not - 6.5.22 to support the mips3 machines.
2) Whichever will make faster binaries
3) Both

/opt/neko with lib|lib32|lib64 would be super ...