I found a blog post about using Gem’s Gzip::TarReader. Sweet. And easy enough to adapt for my purposes. It’s a huge speed improvement over Minitar::Shy.xzf
The packaging tests was going well until I got to Shoes/Windows which just hung when trying to pack a Linux .run or and OSX .tgz distribution. Windows doesn’t have a symlink available to Ruby. Why it hangs instead of throwing an exception is a secondary problem (probably a method_missing somewhere in Shoes). It turns out OSX didn’t need that symlink, so I no longer create it. OSX packaged but it doesn’t run because the +x bits aren’t set on some of the shell scripts and shoes-bin and others. Same problem for packaging for Linux from Windows. It should not have surprized me that Windows doesn’t maintain permissions. Everybody knows that, right?
That’s a game stopping oversight. Time for plan A, B, and C.
(Plan A): It would be relatively easy (as these things go, [snort]) to go back to using Binject for creating .dmgs for OSX which creates in memory hfs+ file systems.
(Plan B): try writing some lines of shell script that set the permissions of the known files and cause the launch script (which may not be +x) to execute them. That would work for Linux because of how it’s launched but is’s hacky and patchy. It also won’t work for OSX
(Plan C): Just ignore the problem. I don’t really care about Windows (they can package for Windows just fine) and as I’ve said before, packaging really shouldn’t be used, although I’ve weakened my argument by making the download and extract run fast enough to not suck.
Plan A also could be used for packaging Linux. Create a dmg, uncompress and put the linux tar ball in it (in theory it will save the permissions bits and I could fix it if it doesn’t – it’s only C). Then [wave hands] dump the +hfs with a GZip::TarWriter [wave hands again]
Or I could use plan B for packaging for Linux and Plan A for packaging for OSX or maybe something else.