Plan 9 from User Space

[yiyus]

I would like to submit plan9port [1] packages for tinycore.

I currently have a package with a script that downloads the latest version (tip, there are no releases), compiles it, and create the corresponding package. I would like to know what is preferred, to include the package with the installer, or to include the generated packages.

On the one side, the script is very small and would require (almost) no maintenance, while the packages would need to be updated with some frequency (but not too much, p9p changes very slowly nowadays). These packages would take much more disk space in the repos (about 70Mb). On the other hand, with the installer package, people would need the compiletc packages (I don't think this is a crazy requirement for potential p9p users) and would have to wait to compile them, which can take a bit long.

In case compiled packages are preferred, then we would have to decide how to split them, if at all. I know the standard here is separating doc and devel packages and so on, but these limits can become fuzzy when talking about p9p. There is some partitioning already defined by p9p, but in fact a user would need to load most of them to do anything. In my opinion, a huge package would be more practical, but it goes against all the tinycore guidelines, so this may be another argument for the script.

What would you suggest? I am more inclined for the installer, but any idea will be appreciated.


[1] https://swtch.com/plan9port/

[hiro]

Hey yiyus,

I have a plan9.tcz that I never updated since 2012 in my tce dir and still use it regularly. So I agree the updates aren't super important. It just consists of the /usr/local/plan9 folder. I agree seperating into -dev and -doc would be pointless in the case of p9p.
I never submitted it because of the size issue you raise. I felt like it would make more sense for people that already are used to the plan9 way to just download the source themselves and create a symlink to /usr/local/plan9 with the real files somewhere in persistent storage. It's what I did on a second of my machines.

Either way I would be happy to see it here to promote plan9.

[yiyus]

Hi hiro! It's nice to find you here.

It looks like we agree some kind of installer is a better idea than submitting one or more packages with the compiled tree. Maybe we can also agree in how this installer should work.

I already have a tcz package that downloads p9p, compiles it and installs a plan9.tcz extension which I think is fine. It just needs some cleanup. I think that including the plan9 tree in the backup is not the best option, between other reasons there is no need to encrypt and decrypt it. It may be needed for example for mail, but I think we can handle those cases individually.

A fancier option would be to store the plan9 tree in venti. We can make a very good guess to decide the optimum size for everything, create the arenas in the USB drive, and install a package that restores the tree from the venti server when it is installed.

My plan is to get a plan9port-getLatest.tcz package into the repository and, maybe later, consider a plan9port-venti-getLatest.tcz which uses the venti-based approach. Then the user can install whatever he prefers. Depending on the results with my experiments with filetool.sh alternatives (that you saw in the other thread), I may consider submitting a venti-only extension (if that is feasible), so we will see.

[hiro]

I personally don't use venti, so I can't advice on that.

After first going mostly your route with my package I would think my second approach would be best:
-prompt user for a persistent install location
-create one symlink from /usr/local/plan9 to above location
-add the symlink to filetool.sh.

The user then needs to see how he adjusts the path and mounts the disk on demand unless it's already mounted. I personally have a bourne script in my ~/bin that mounts sda5 and then does the same thing as the original 9 script.

To suit users who might not have a usable persistent filesystem (e.g. only case insensitive fs or boot from CD) you could have a prompt like this and offer both options:
"Enter persistent installation dir or leave empty to create tcz (about 70MB)"...

You could also make it two prompts: one for persistent source dir and one for deciding whether you want to create a tcz or not.

[yiyus]

Fair enough. I always run tinycore from usb in a windows machine, so I was not considering persistent partitions. But you are right, if you have persistent storage that you can just mount, that's the best place to install p9p. However, I would prefer to avoid prompts, if possible.

I propose this: when plan9port-getLatest.tcz is installed, the plan9.tcz and plan9-tree.tcz extensions are generated. The plan9.tcz extension would include a tceinstalled script to find the tree given in a PLAN9 boot option or load the plan9-tree.tcz extension, and a /etc/profile.d/plan9.sh file to set the PLAN9 and PATH shell variables. In the plan9-tree.tcz extension, we include the whole tree and a p9p-install script that copies the tree where you want and adds the corresponding PLAN9 variable to your boot options.

This way, if permanent storage cannot be reached, you have a backup plan9-tree.tcz (which you can delete if you will never need, we could also avoid its creation if the PLAN9 boot option has been set before getLatest is loaded). I like this approach very much, because at a later stage we can support venti servers as PLAN9 boot options. What do you think?

[hiro]

It seems difficult.
If you want to avoid prompts I think it would be less confusing to only have a plan9.tcz with everything included and already installed and no other options for the user. If the user wants more he can do it himself like I do on my other machine.

[yiyus]

I think I have found a good solution. The script is indeed a bit more complex than I would like (~100 loc), but I think is worth it. The extension only has a tce.installed file and a plan9-install script.

The main use case will be loading the extension from a new system. The tce.installed script will run plan9-install and the next reboot everything will be ready to be used. In the case $PLAN9 is set, nothing is done, but you can run plan9-install to generate an extension from there. You can also use it later to install from this extension to another location. This is the complete help message:

Code: [Select]

$ plan9-install -h
Usage: plan9-install [ TARGET ]

Create a plan9.tcz extension from $PLAN9, if available, or from the latest
version in github. In the former case, create also a plan9-local.tcz
extension that loads plan9.tcz when the original $PLAN9 is not found.
If TARGET is specified, install there first, later create plan9-local.tcz
and, if installing from github, plan9.tcz.
.