Thinking out loud – linux packaging

Perhaps you’ve detected a love/hate viewpoint from me when it comes to packaging. I’m the only person who is willing to admit knowing about the insides (other than _why_the_stiff). That doesn’t mean I’m correct. It just means I think I can do something about the current state — which is actually worse than I wrote about in my last post because at the time I was update Red Shoes I’d chosen to do nothing about packaging.

How should it work. Think like an end user first. They download something, they cause their Operating System to execute that something and then presto they are looking at your GUI application and have no idea it was written in Shoes/ruby. They might have an icon on the desktop or in a system menu so they can run the program again.

What has to happen for that ‘vision’ to work cross platform? They need a version of Shoes 3.2 for that operating system and the execute that something installed it. No big deal because you packed your app with the right Shoes platform (7MB or so in size). In Linux, that Shoes was never really installed as I described above, it just got reinstalled when the user ran your download app. That’s a serious annoyance for resource constrained platforms like the Raspberry pi.

There was a ‘download shoes if needed’ option. It’s been broken for years and it wasn’t clever enough in Linux to deal with Intel (64 vs 32 ) or ARM versions of Shoes/Linux. I think that’s fixable since the bash code to download and install Shoes with curl and or wget was already written – it justs need fixing. Testing is a major pain so I down’nt blame anyone for not doing it. Theres a lot of ways to get it wrong even when it looks like its working.

Current thoughts: Modify the static/stubs/sh-install to know where the current shoes lives on the web (remember the cobbler ability to change that url which happens at user install time, not at packaging time). Downloaded Shoes Apps should be kept in one place like ~/.shoes/+apps. It might be a single isp.rb file or an expanded hh.shy directory and the starting script within.

There’s a compilication (one of many). Linux uses the makeself ‘package’ and it can’t handle two separate tar balls inside, Shoes+Ruby and a separate Hackety Hack like directory structure. That’s why HH want’s to be built from source so it can duplicate/replace parts of Shoes. My current idea is: when packaging a .shy (tar’d directory) it will be copied into the Shoes tree under apps-install-{name} or something like that so all the images and binary stuff in {name} are part of the big tar ball {name}.run and when that is run on the users system, Shoes will install into ~/.shoes/federales and the apps-intall-{name} will be copied to ~/.shoes/+apps

Saddly, this brilliant brain fart may not work if you want to package a complex app and “Not include Shoes” since there is no Shoes to hide the app-install-{name} tree inside. I suspect I can find a solution. Actually, what Linux people want (IMNSO) is not to include Shoes but to download if needed. That’s certainly something I have to try first and then see how it can meld with the above vision. Cowboy coding or design for perfection?

Since I’m an maintenance programmer and lack vision, I’ll probably go cowboy and see what happens.

Leave a Reply

Your email address will not be published. Required fields are marked *