[Raion]

Ok, so this is purely an exploratory thing that I'm talking about. It's about how to overhaul tardists while retaining some level of backwards compatibility to the old system. As a result, here's the "rough draft" of the package format white paper I have. 

Improvements and Goals

Tardists have multiple flaws: weak compression algorithms, difficult to use tools, package signatures,  incomplete dependency resolution and they're a pain in the ass to maintain and use. 

So, as a result, we have five goals to do with replacing it:

1. support better compression algorithms
2. easier build process
3. optional package signatures
4. Better dependency resolution
5. Better scalability. 

Tardist legacy structure

Every tardist is a .tar file containing an idb containing binary offsets, a large concatenated binary, and a few helper files. 

Proposed file structure
Same .tardist extension or similar, with an uncompressed tarball at the top level. Inside however, are differences:

1. A marker file indicating it's a new format. VERSION2 with the string "tardist" inside would be the official way to do this. 
2. A tree of the files for installation. so for instance usr.nekoware.tar.xz with the interior being the bin, lib, etc. compressed in xz or zstd format 
3. an OPTIONS file that the package manager can read if it contains multiple versions of the same binary (e.g. for mips3, 4 or 64-bit) 
4. a MANIFEST file containing all the subsystems it has. This would enable compatibility with tardists. 
5. a REQUIRES file that contains the subsystems that are needed to be installed beforehand. 

Coupled with this is a repository structure:

Proposed Repository Structure
A flat directory of all tardists for installation. CONTAINS.lst is a list of all tardists, their subsystems, size and checksums. 

CONTAINS.lst would be autogenerated by a perl script that reads the MANIFEST file for it. 

The inst or similar installer program would download and cache the CONTAINS.lst file when a repo is installed. It then uses this as a guide when installing programs for how to resolve dependencies. The repo can also have optional "lists" for standard installation that can auto install all necessary packages for a given config. 

External programs will be called to download the repository, such as ftp, gemini, http etc. 

Package generation

You would install the packages into a root directory when building it the first time (e.g. /usr/packagebuild/packname as prefix) and use that to generate a tree of the files using a program. Then you'd change the make options and reinstall it to /usr/nekoware. From here you'd make a spec file much like with a tardist, and then point to the spec and file tree along with a constructed OPTIONS file. It would then build a dist of it, then if you had other OPTIONS you'd set those up too. Once done you run a final command which sets up the MANIFEST, REQUIRES and final structure free, you compress the directory into a tardist. Boom, done.  

Where I need help
1. If you've previously worked on a package manager and have opinions, please state them. I'm open to suggestions. 
2. If you've got an opinion on how I suggested this, please feel free. 
3. How to implement signatures the right way is always welcomed. 

FAQ

1. What about RPM?

If you've ever worked with RHEL for any length of time you'll understand why I'm not a fan, and moreover RPM uses CPIO and doesn't retain backwards compatibility. 

2. what about <insert format>

Feel free to start your own thread and we can talk about that. See backwards compatibility as to why I proposed this. Multiple package managers on one OS is a BAD idea, especially if they can't talk to each other. 

3. Do we have what we need? 

We got a new inst(1) I had made by TruHobbyist. It's FOSS. We can extend it as necessary. 

4. Why not just use X tool and retain tardists

Tardists remain a pain to build. Let's not make this complicated.

[weblacky]

Without it sounding like a joke, as long as you have a tardist to install the new tools :-)

If you want acceptance and ease of use of anything the out-of-the-box experience is going dictate that. If I can load a fresh install of Irix and download something and press install via the built-in installer in the operating system I'm more apt to use it than if I have to run a bunch of scripts or I have to compile anything, to start.

I'd also ask that you might consider extending your format idea just like SRPMs did. A source version of a package that has tools that check for the SGI compiler or something would be a good idea. Obviously that may be a back burner sort of thing but I'm just saying you might want to put the stubs in your design so that there's not some version three or version four of the tool, instead you can always implement a little later but think of the idea of having builds that require the compiler.

Also on a side note, I tried to look up how to create tardists several times but only found partial information. Does anyone actually have complete information on producing one? Because a part of me thinks that the above comment of their pain to make is just because we don't have a tool to help us? If we better understood the process perhaps we could write a tool that makes tardist creation easy?

I like your idea of extending the format we have in a way that may not break the original installer. I think that's the smarter way to evolve this.

[Raion]

There will still need to be rules made for the new installer but inst is now FOSS so we can actually write routines for it and such.

[vishnu]

There will still need to be rules made for the new installer but inst is now FOSS so we can actually write routines for it and such.

Where is the source code for inst?

[Raion]

http://contrib.irixnet.org/truhobbyist/inst_bundle.tar

[weblacky]

I get a not found error on this entire folder, can you check? I'd be interested in seeing the code as well.

[Raion]

http://contrib.irixnet.org/truhobbyist/

Remember there's no SSL on these subdomains. Do not let your browser force SSL.