Being one of the Nekoware beta contributors, i'd like to chip in and say something, hopefully, relevant.
Nekoware Beta is called like that, because it it Beta software. Period. As such, the packages can vary in appearance, like what you see in inst/swmgr, dependencies, and even subtle things like versions on DSO's (Remember the zlib issue a while back? Exactly.) and even bigger things like not running on 6.5.20m.
Granted, not everyone is satisfied with the exact appearance, permissions and ownerships of the installed packages. Give us some slack. It took me a month to do kdelibs and kdebase. Not because of the porting, that took a week, but because i had to swim through swpkg and dependencies and making dozens of versions before i had everything correct. With half-a-gig to build this wasn't something to be done overnight. Also i received feedback from my first QT build, ranging from missing headers to feature request like the mysql plugin, which i thought was great, because people looked at my package and commented on it! I fixed the headers and qmake, but no plugin yet for Mysql (sorry Theo)
My respects to Nekonoko for building the openssh/openssl packages. I use them on my I2 High Impact and it works just like a peach. High hats to others who contribute over there. Yes, i do have 6.5.22m and MPRO 7.4.2 + all patches. But i'm not a snob about it. If someone has issues with any Nekoware Beta package, please PM me. I have the luxury of multiple machines at hand running various versions of OSses, so i can always build something if need be. Please be also patient with the irix os version. It can't be long now for 6.5.21m to be released in public.
As for the swpkg format, Neko is right in his stance adopting freeware layout. Scripts are important, though i haven't used them much. Config files are even a bigger issue, and that can easily being done in swpkg, which i did with respect to kdelibs/kdebase.
We can't please everybody with our interpretation of tardist format. This is something which should grow over time. I also believe that the contributors have a feeling of making tardists because they want to use that software, and to me, this also means a clean install in inst and having the correct dependencies. Make it a group effort and steer people who have problems creating proper tardists, but lets not forget the good spirit of each contributor, which feels (justifiably) proud of his/her (porting) achievements.
Take a look at neko's openssh tardist which is a fine example of a well processed package. I use this as a stepping stone for my build, and i intend to improve my Qt/KDE stuff using this format.
My 2 cents...