Towards a packaged distribution of the PiSCSI software

[funkyfuture]

initiated from a discussion about proper installtion paths,
i tried to get an understanding of the possibilities and challenges regarding
the distribution of the RASCSI software as Debian packages.

the motivations for that are:

• simplified, streamlined software installation & updates
• possibility to cleanly uninstall components
• simple backup and restoration as only configuration and user data needs to be
  considered
• separation of concerns as a architectorial sideeffect
• reduced power and time consumption among the user base

i found one aspect to be a major concern, that is the dependency on other
software that is also not (yet) available as Debian packages, namely:

• hfdisk
• MacProxy
• Netatalk

i can think of three strategies to deal with this:

• inquire whether the software maintainer's are interested in providing Debian
  packages themself
• create packages within this project
• just keep distributing a helper tool that facilitates installing these
  components from source

what also should be figured out is how an apt repository could be provided to
distribute the resulting RASCSI packages. i haven't done any research on that.

the other aspects and tasks that i found necessary are included in the draft
for a roadmap.

Roadmap

• establish a scheme for configuration files
  • as the daemon and the web frontend are system services their configuration
    should be located within /etc
  • as it opens the question of of legacy support, the possibility to use one file format, and more, this certainly deserves its own issue
  • should this include a possible wifi-setup as qol?
    (so that a user that runs a standalone deployment just needs to handle one
    set of configurations.)
• consolidate the Python software
  • host them in one or multiple repositories?
  • make a proper Python package (with setuptools) or one per component
• factor out disk image related tasks from easyinstall.sh to seperate
  scripts
• package all rascsi components as .deb (source and binary)
  • rascsi as meta-package that depends these:
  • rascsi-daemon
    • includes disk image related scripts
  • rascsi-python-tools or rascsi-{oled,pylib,web}
  • rascsi-docs would be optional and include all docs incl. hardware
• create a meta-package that depends on all Macintosh computer specific
  software
• update the easyinstall.sh with hints to replacing modes of use or just
  drop it?
• find a feasible hosting solution that the CI can upload to

please let me know when i should be more elaborate to clarify things. or amend
/ correct things, any feedback is appreciated.

regarding myself, i'm not even a RASCSI user yet and i don't have the time to
coninuously participate in another project. but i could certainly help with
progressing the Python parts and the actual packaging.

[akuker]

Great suggestions! As I get more time, I'll mentally digest this as I get more time.

Regarding the .deb packages - I've been thinking of going more the embedded route (potentially a buildroot image). There are pros and cons to both, I suppose.

[funkyfuture]

with "embedded route", you mean distributing disk images for SD cards. do you? this seems not too ergonomic for software updates to me.

i'm certainly interested in a pro/con-list for that matter.

[akuker]

One of the biggest complaints I get about RaSCSI is the boot up time. Using off-the-shelf Linux distros doesn't help with this. With a pre-made image I can do things to speed up boot time.

I'm curious if most users have the Raspberry Pi dedicated to the RaSCSI function, or if they're running other things on there.

Ultimately, both are good methods to distribute the software.

[stevebourg]

One of the biggest complaints I get about RaSCSI is the boot up time. Using off-the-shelf Linux distros doesn't help with this. With a pre-made image I can do things to speed up boot time.

I'm curious if most users have the Raspberry Pi dedicated to the RaSCSI function, or if they're running other things on there.

Ultimately, both are good methods to distribute the software.

I don't intend to use my RaSCSI Raspberry Pi for anything other than RaSCSI related purposes, but I do hope to use the extended facilities of Linux to enhance my RaSCSI experience. Example: bridge the Daynaport NIC into a L2 VPN so that I can play AppleTalk network games over the Internet. Needs support for the TAP device, might make use of ebtables, and might upgrade the version of Tinc VPN from what is available in standard repository.

[rdmark]

See #1173 for some discussion on the potential install location for piscsi files.

[rdmark]

as part of #1734, piscsi variable state files are now installed to /var/lib/piscsi by default, with the possibility to customize the location at compile time of both piscsi proper and the new Go Web client

what remains to do here is Debian deb packaging of the piscsi software, which should be straight-forward now when Python has been eliminated