[Raion]

After reviewing a significant amount of information on various attempts at IRIX package management, and better understanding our limitations, here's my thoughts on what we should try next:

Recreating inst/swmgr as a FOSS drop-in replacement. There's a few reasons behind this line of thinking and thus hopefully I can help explain the rationale behind it:

Some users have recently ported RPM to IRIX, with the intention of making it easier to port software into IRIX. Let me underscore that I think this is not a bad thing, but I think that brings in a few challenges. For one, it echoes IBM's AIX. For those unfamiliar, you have technically two ways of installing software on AIX: Filesets and RPMs. These systems don't really talk to each other, which means there's a potential for destructive changes to the OS by a poorly written fileset overwriting an RPM or vice-versa. I have not proven this to be the case, but there's no interaction between the two, since the RPM port is just a straight port of the Linux version. There's ways that RPM on IRIX can potentially be implemented to get around this, but hear me out. 

The major issues aren't with the tardist format, but the limitations of the IRIX inst/swmgr program at managing dependencies, limitations with handling formats, and more. 

If we have someone recreate inst, this would solve a few issues:

1. It'd retain a centralized way of managing packages, and allow features to be added like HTTPS, FTP etc. retrieval, package signing and verification, smarter conflict resolution, and even frontends or hooks to allow RPM to work non-destructively, or any other package system.

2. We would be able to roll something similar to an SRPM (source rpm) or a raw tarball that could still be implemented into it. Again, this could all be extended in a FOSS version.

3. inst seems to have trouble with both gnu and bsdtar if you use them to replace IRIX tar. There is, however, nothing stopping a bsdtar or gnutar from the base system other than the inst problem. Replacing inst/swmgr would give us the ability to permanently replace IRIX tar with a foss equivalent. 

To that end, I'm willing to put down some money to pay someone to do this, assuming they do it under a permissive license (BSD, Apache2, MIT, ISC, zlib) and keep the source code well documented. If others feel the same way, let's get a bounty started somehow. If others have better suggestions, I'm all ears.

[Raion]

I personally prefer BSD tar and illumos tar, just saying. But there's no specific reason I'd lock gnu tar out if I were the architect of it. If you catch my drift, it's a choice thing.

If I had it my way with the project, inst would only offically support the bsdtar packaged in libarchive, and using the stock IRIX tar or GNU tar would be an unsupported venture unless they have patches they could maintain upstream. Like with almost anything here, I'm not skilled enough to do it myself, so I'm a bit less picky.

[mgtremaine]

I get where you are coming from.

I wonder if it would be possible to create a sync layer, some tool that could read RPM database and write inst/swmgr entries?

Having used YUM/RPM on AIX many times I find it super useful. But I admit to my bias, since 1997 I've used Redhat's and RPM based Linux when I've used Linux. On AIX you install only as much as you needed and let the base OS and add-ons do it's thing, it was pretty clean. I could see that working well with IRIX but the Nekoware and Freeware additions make it a little more murky because of the dependency issues.

What you don't want is the more recent homebrew and others where you install 1 package and pulls 30 others at 2GB of space as you claw your eyes out while trying to stop the thing.

-Mike

[Raion]

Well on AIX, AFAICT, filesets are mostly from IBM, and RPM from external vendors. AFAICT, that is. I've only admin'd AIX briefly and using troubleshoot manuals extensively.

Well creating some kind of hook would probably be already halfway to implementing inst, and you also need it to work the other way to ensure that you don't have to install RPM dependencies twice.

Now, you can prefix RPM or run it in a chroot to only give it access to installed pkgs. That can work, but that requires you to basically duplicate many of the same things twice or thrice or even four or five times over depending on the *ware you're running. you can also manually resolve libraries to installed ones, but that requires trust that I think only idiots should give to their system and to the user when writing guides. You gotta reasonably idiot proof a guide so that someone with a below average IQ isn't gonna skip common sense logic and follow it to the letter.

[Raion]

Documenting some of inst's eccentricities:

It uses /var/inst/hist, an ASCII file, for storing what distributions are installed. This could be reverse engineered to serve as a basis for a new inst.

[mgtremaine]

From my recent fumbling around with it I noticed (maybe I'm wrong) there is no way to force uninstall (ignore conflicts). You can upgrade and downgrade but not force. Would be a nice addition.

-Mike

Added: I was wrong, no surprise. You can force install via "set rulesoverride on".

[Raion]

Yeah, a lot of innovations could be made. We don't need ti start out to fully replace inst, even if someone can make python scripts to manipulate the contents of tardists and the hist file, we can start getting ideas about how it works.

I'm not smart enough to replace inst.

I'm trying to figure out who to ask to look into this.