[Raion]

As some of my recent posts have suggested, it has been my intent to bring back Nekoware. While there are concerns about package quality and such, several individuals such as Canavan and Dexter1 have been quite prolific. Because of these developments which have continued, plus the failure of irisware, I have decided to revive nekoware, by myself if needed. 

I was gonna wait until I had more on the table, but we're now racing the beam against other efforts, and I feel that there's no point in hiding it. 

Now a few things to note about the revival:

1. I'm keeping this separate from IRIX Network; primarily to facilitate cooperation with other groups. I'm still going to lead efforts, but rather than gatekeep based on package quality, we're going to go back to voting for packages to be upgraded. The host for this is will be at irixce.org, which stands for "IRIX Community Edition". Forum discussion will be mostly done here, but if there's demand we'll add forums there. I would prefer to go easy with this and only expand infra as necessary. 

2. Packages will be required to be maintained to be included in the new nekoware. This means that we won't be dragging along old packages without maintainers. The goal is to bring things forward when possible, but to stave off issues from this, we will for now be linking against currently existing nekoware libraries until a replacement has been promoted, which is some of the packages I've made. Reproducibility is very important, so I'll try to test for each package and spec/idb file. If we have the swpkg spec/idb files, then a chimp can technically rebuild a tardist. 

3. Tardist tutorials will be updated with screencaps, easy to follow instructions, and if i could figure out video capture, or perhaps coach either Irinikus or Intuition to help with tutorials. 

Nekoware will take a page from pkgsrc though, and eventually have a "release" channel in addition to current and testing. What this will be is a quarterly compilation of the stable software for IRIX. You can think of it this way:

Testing - New packages that have been submitted but not fully tested or voted on
Current - Packages that are tested and submitted, and contains the latest and greatest. May have dependency bugs or occasional bad eggs that slip through the cracks, but mostly stable.
Release - A quarterly compilation done in March, June, September and December of each year that is verified to all work together without clobbering things, and is beginner-friendly.  

That does it for Nekoware stuff, now onto what "IRIX Community Edition" actually means, and what it entails:

1. Once I figure out and have documented and gotten experienced with tardists, it is planned to take 6.5.22 (simply because it's more widely supported) and go through the distribution, remove old programs that are no longer needed, secure the system by default, and clean up the system, possibly with the help of those public domain scripts I'm building, to make things easier to get started. 

2. IRIX Community Edition will have distributions for desktop, server, etc. cases. We're taking a legal risk here repackaging IRIX, but it's my hope that HPE will look the other way for the sake of the community. This is one reason why everything involving IRIX CE will be separate from IRIX Network, it shields my partners in the site from legal liability, and it'll be likely that IRIX CE won't be distributed directly on irixce.org or here, but instead through secondary channels that keep us safe from piracy complaints. 

3. IRIX Community Edition upgrades, not the source or components of IRIX itself, will be an open specification that anyone with the proper skillset can fork/replicate/make a custom distribution out of. 

Some things to note. I don't plan to overrule the entirety of IRIX CE or the new Nekoware. If someone's willing to maintain a package, even if I don't like it, I'm going to include it in the distribution. But I would hope that we can encourage people to not encumber newer packages based on dependencies that not everyone needs/wants.

Other notes: Patches will be mandatory to include if used, but not original source code. I've decided that for disk space purposes, the opt.src part of the distribution will be optional.

For starters, here's a template nekoware spec file:

Code:

product neko_example
    id "Name your package here"
    image sw
        id "Software"
        version 20
        order 9999
        subsys eoe default
            id "Execution only Environment"
            replaces self
            exp neko_example.sw.eoe
        endsubsys
        subsys hdr default
            id "Headers"
            replaces self
            exp neko_example.sw.hdr
        endsubsys
        subsys lib default
            id "Libraries"
            replaces self
            exp neko_example.sw.lib
        endsubsys
    endimage
    image man
        id "Man Pages"
        version 20
        order 9999
        subsys manpages default
            id "Man Pages"
            replaces self
            exp neko_example.man.manpages
        endsubsys
    endimage
    image opt
        id "optional components"
        version 20
        order 9999
        subsys relnotes
            id "Release Notes"
            replaces self
            exp neko_example.opt.relnotes
        endsubsys
        subsys dist
            id "dist files"
            replaces self
            exp neko_example.opt.dist
        endsubsys
        subsys src
            id "Source Code"
            replaces self
            exp neko_example.opt.src
        endsubsys
        subsys patches
            id "patches"
            replaces self
            exp neko_example.opt.patches
        endsubsys
    endimage
endproduct

Copy this file and save it as neko_template.spec, and then you can use to get the spec file automatically filled in. (I've set the increment # to 20, simply because I don't know the methods used for old packages)

Spy snapshot of completed tardists. More to come.    

[Axatax]

I had a very nice conversation with Raion tonight, and I subscribe to the premise of resurrecting something like a spiritual successor Nekoware.

We need a solid design document that lays out the goals and philosophy of this project. I'm going to do that. I'm not qualified to do that vs. anybody else here. I'm just taking an initiative. The document will be put up somewhere accessible, and linked here, and then everyone will be free to hammer on the document, disagree, make death threats and propose changes to it. But we'll have a starting point at least.

Fundamentally, I think we have a very small community with a very big fracture. Philosophically, in terms of a future SGI software distribution, I support a very tight base of software compiled with MIPSpro, with high-level stuff compiled with a modern GCC if that's what contributors want to do. I support traditional SGI .tardist packaging with a Python script to approximate a Linux-style remote software update aka. apt-get.

Now the first two technical things -- I want users of Nekoware (I am one) to be able to use their existing software, and two -- I don't want the distribution to be called Neko-anything, and I'd like to see it reside under /opt. If we can agree on all this, we can maybe get a new successor to Nekoware off the ground.

[Raion]

I'll publicly say I think for now, we can retarget our testing release of nekoware in /opt/nekoware. We can revisit, months or a year down the road, if we are ready to move or if we should stick with it.

As far as dependency resolution goes, Dodoid brought up the idea of a foundational library set for basic prereqs. I think we should consider the same for the interim at leaat. Common libs all being pulled in will make it a bit less onerous for both devs and new users to test software.

I don't mind python personally, but I'm unlikely to write some kind of nekodeps on steroids. I have the irixce stuff to worry about, as well as the web dev.

[Raion]

Just update everybody there is an ongoing discussion about whether or not this should be called nekoware.

personally I don't have a problem sending this out to the community but I don't want it to be called irisware, irixware, sgiware particularly. Anything like that generally tends to bring in connotations that either exclude other ongoing projects like irixports, or bring up questions regarding whether or not the name matters.

it does not appear that Peter really cares about use of the name and personally I would rather this to be implied to be a continuation of what we already have rather than a clean break so to speak.

That being said I'm trying to emphasize here that I'm only one person involved in this project and most of my efforts are focused on actually working for the project in capacities that other people are not necessarily prepared for.

With all of this in mind I would hope that community members would be willing to speak their mind and perhaps help guide our hand here because it's not about what I want or about what the other administrators want since we're not in the primary users of the software project.

I'm mostly a system administrator so I'm only really maintaining the infrastructure and also doing things like documentation and packaging as well as the occasional port for things that I find useful. While unexpected, it is great that we have more people getting involved because I was afraid that this was mostly going to be a solo effort.

So yeah it's open season for comments.

[commodorejohn]

It's a continuation of the nekoware project, to which nobody else (certainly not Pete) seems to be laying claim as of the last couple years. Don't see an issue with keeping the name.

[Raion]

Your input is appreciated John.

[CB_HK]

I think Nekoware would be fine to continue using if most folks are also ok with it. If not, there's always an alternative way of naming things if an acceptable name can be conjured up. Otherwise, my vote remains to just keep with Nekoware for the sake of familiarity.

That being said, both concepts Raion has laid out are exciting and something that I think the community could certainly rally behind.

[Lady Serena Kitty]

Yay new Nekoware! I can haz Nekoware?

[Axatax]

FYI --

I don't have ANY hard feelings at all about Nekoware or Peter, who I didn't know, and never spoke with personally.

The idea with using a different name, is a pragmatic one, so we avoid incompatibilities with stuff like path names.

If you want to continue using Nekoware as a name, may I please recommend using /opt/nekoware, and not /usr/nekoware.

Let me know what the consensus is, before I start to build the reference packages.

---

If we can agree on the new stuff going into /opt, then we can keep everyone's /usr/nekoware, which I agree with.

---

I'm also agnostic to using something like yum or apt to sync remote software repositories, but I **really** think we should stick to SGI (.tardist) packaging.

[kaigan]

The idea with using a different name, is a pragmatic one, so we avoid incompatibilities with stuff like path names.

If you want to continue using Nekoware as a name, may I please recommend using /opt/nekoware, and not /usr/nekoware.

I agree with Axatax on this. I don't personally have strong feelings regarding the use of the Nekoware name, though I'm perfectly happy to see its continued use. However, given that there is a "historical" Nekoware project with numerous packages that may be of interest to people in maintaining on their SGI systems, using a new path such as /opt/nekoware makes a lot of sense. My thought is that this revival should be self-contained and able to coexist with its predecessor as much as possible.

I'm also agnostic to using something like yum or apt to sync remote software repositories, but I **really** think we should stick to SGI (.tardist) packaging.

I also think that maintaining the use of IRIX components like .tardist packaging should be maintained where possible. While I like Linux and use it daily, I don't think we should be turning IRIX into something that looks and quacks like it, so to speak.