MindlessCode.net

Autopackage has a pretty decent API that does everything from comparing versions, to finding shared libraries, to installing menu items. A while ago, in a comment on Mike’s blog (can’t find it now), someone suggested writing bindings for the Autopackage API. At first I wasn’t sure if it would be useful, but now that I’ve thought about it, it’s seems like it could be pretty handy.

I know that there are corporate lawyers at ISVs who are just going to require an EULA to be displayed and accepted before any files land on disk. This ISV would like to provide a Linux version of their software, but their lawyers and managers require the installer to display an EULA and serial key check.

I think this is a case where libautopackage (or whatever it’s called) could be useful. The company writes their installer in C which handles all the interaction like showing EULAs, checking serial key numbers, showing screen shots, playing stupid music, etc. Meanwhile, libautopackage is chugging away in the background, checking/installing dependencies, installing menu items, updating environment variables, and doing whatever it is that installers do.

The ISV gets several benefits that they wouldn’t get from rolling their own installer:

• Our binary compatibility tools (well, they could use them without autopackage, but it wouldn’t be integrated).
• Dependency Checking/Resolution
• Our non-Autopackage APIs like compareVersions(), isInList(), getKey(), and stripDupedItems()
• Our APIs for installing distro dependent stuff like menu items and MIME types

And some other stuff as well, like their program is listed in the package manager, statistics on installs, auto-updates (maybe, in the future? I think Curtis may have had some code for this…), etc.

Some of this can be accomplished by the ISV writing a new frontend for Autopackage. However, a new FE doesn’t exactly have the same flexibility as a new installer.

One example of where this would be useful is an office suite. Often times, an office suite has optional addons (such as extra file format converters, language packs, etc). The custom installer could ask the user what they wanted installed, then use libautopackage to install the core application and each optional component as an Autopackage.

Writing the bindings probably wouldn’t exactly be easy, as Autopackage is written almost entirely in bash, and is most of the APIs require global variables to be set, like $PREFIX, $WORKING_DIR, and $AUTOPACKAGETARGET. Also, I’ve never heard of bindings from bash to C, it could be pretty slow (starting a bash session each time a function is called!). And no, rewriting Autopackage in C doesn’t really sound like fun!

Anyway, it’s an idea…very possibly/probably just more inane ramblings from Taj. Thoughts? Good idea? Bad idea? Impossible to implement? Leave a comment!

Random Item #1:

Are you going to have a wood stove when you go to college?

– Mary, responding to my comment about how slow it is to cook on a gas or electric stove.

Random Item #2: OpenOffice.org doesn’t rock! “What!?!” I hear you cry, “How can you say that?”
Yes, it’s true–I’ve been teaching my dad to use Impress to create a presentation, and I can say that OpenOffice.org is not that great (heh, to say the least). For example, the UI layout really doesn’t make too much sense:

That is, the “Add Slide” button (which looks like a green plus sign plus the words “Slide”), the “Slide Design” button, and the “Slide Show” button. What do these 3 buttons have to do with each other? Nothing, as far as I can tell–except that they all have to do with slides–like the whole program does :S… There are a bunch of other examples, but I’ll spare you more UI ranting from someone who knows nothing about UI (that is a screenshot of QuickI, the invoicing program I wrote for Wild Garden Seed–it completely sucks, but if anyone who wants a POS system that sells products by weight and supports price breaks, let me know and I’ll send you the code).

Random Item #3: We’re about to roll beta3 of Autopackage 1.2. Please, please, please, we need testers! Get ahold of us however you want to, #autopackage (on freenode), the autopackage-dev mailing list, or the forums, and we’ll get you setup. Thanks!

Random Item #4: Lost in the great bit-bucket (/dev/null) because Firefox crashed again! (For the third time while writing this post.) It had to do with the instability of Firefox–no suprise there. It seems like it has something to do with uploading a file and using the new GTK File Choosers… /sigh

Random Item #5: Does anyone have a Linux box with g++-3.2 and g++-3.4 installed on the same box? If so, would it be possible to let me have SSH into there? I need to find a system with those two versions of g++ (3.3 doesn’t work) so I can double-compile the Scribus autopackage for testing. Contact me, or leave a comment (with your email address–it won’t be displayed), and we’ll try to arrange something. Thanks!

DRM ‘manages access’ in the same way that jail ‘manages freedom.’

Slashdot Signature

Great point. (* tmorton, who is frustrated by ATRAC3 on Sony’s MiniDisc.)

A beta of Autopackage 1.2 is slated to be released sometime this weekend and we are going to need lots of testers! Swing by and let us know you want to help test. Thanks!

Mike has setup Planet Autopackage and Isak created the design. It’s running off the Planet aggregator software. Hello, Planet Autopackage!