Re: Status of Installer.app?

[Frederico Muñoz]

Hi,


On 2005-02-15 16:01:17 +0000 Adrian Robert <arobert@cogsci.ucsd.edu> wrote:

> 
> On Feb 14, 2005, at 6:34 PM, Frederico Muñoz wrote:
> 
>> The Installer I'm making relies on bundles to support different package 
>> formats. The expected package info is put on a protocol and bundles must 
>> adhere to it, thus the actual mechanism of getting the info (that is highly 
>> dependent on the packaging format) is abstracted. My main testing bundle is 
>> the .deb one, but e.g. I make a Pkg bundle that could read NeXT/OPenStep 
>> .pkg's (see a somewhat old example at 
>> http://www.gesal.org/gnustep/installer_pkg.jpg). This can be extended to 
>> any packaging format.
> 
> Thanks, I'll look this over, and try helping if I can. 

Don't look at it too mcuh, you might get nauseous :)

Anyway, I'm improving the code night after night.

> I'm most interested 
> in the .pkg format since I want to make just one package that Hatters, Debian 
> people, etc. can all install on their systems.  (If an app gets "healthy" 
> enough, distribution maintainers will hopefully package it specifically for 
> each distribution anyway.)  Are we legally able to use .pkg for GNUstep?
> 

I don't hink there is a problem with the format itself. I don't even know if 
this kind of stuff has any special protection. Anyway, the .pkg format (and I'm 
assuming the OPENSTEP one, not the OSX one) is so simple...

I will put the Pkg bundle on the top priority again then. I have some code that 
I have'nt merged exactly relating to the subproject.

One thing to note, however, is that we can't use a BOM file, at least not one 
in the original format. It's binary and not a single spec exists. We must, to 
provide the same info, decide a suitable alternative, that can be so simple as 
a "find ." with options to show permissions, name, size, etc redirected to a 
file and optionally gziped.

Everything else follows the spec. For this to work (and I always had hopes on 
this, see my article on packages on the wiki) for regulat install/uninstall it 
will not take long. I will have it working in a couple of days, and then we can 
start testing with .pkgs that are made by us (a Packager.app would be useful in 
the future).


This doesn't mean that the old .pkg will forever be a good format, but I think 
that it is a good starting point. After having that one working OK (and, even 
being very simple, it works) more advanced feature can be added.


>> For the multiple steps sequence a problem arises. My idea would be to have 
>> a bundle that supported the OSX .pkg format (basically the NeXT format on 
>> steroids, with preFlight, postFlight, available volume size checking,etc). 
>> This however has a great impact on the UI. I chose from the begining to 
>> base my work on the NeXT installer, that basically presents all the info 
>> and then lets you install.
> 
> I meant multiple steps on the "back end" -- e.g., install a framework, run a 
> script that builds a package or tool using this library, install that, etc..  
> Maybe not that necessary..  I think NeXTstep just put such things in separate 
> install packages, and that wasn't that bad.

Well, you can put everything you want inside a specific bundle, but it will be 
seen as a "single step" if it isn't specified in the protocol and the UI isn't 
designed for it. E.g. in the installPackage method you can put everything you 
want (assuming that it does error checking, etc), but it will be opaque to 
Installer. The opposite would be to have methods like preFlight, postFlight, 
checkVolumeSpace, etc. This is possible, but would need to be put in the 
protocol and all the bundles would have to implement it (although they could 
simply return YES :) ). I would like to reserve this "advanced" features for 
after having the more simple old .pkg format supported.

Also, as far as uninstall goes, I think that even the new OSX Installer doesn't 
do uninstalls :) . I could make INstaller.app do it however, by checking if the 
package that it opens is inside a Receipts directory and using the before 
mentioned custom-made BOM to remove it.

Another possibily would be to also register for *.app dirs, and if the user 
choses the open with Installer (in GWorkspace Installer would be listed as a 
secondary application I think) it can check if the app is in the 3 "regular" 
places, and if not ask the user if he wants to move it there. This isn't very 
important though.

Do keep in touch, this need of yours has the great advantage of keeping me 
focused and knowing the real needs :)


Best regards,

fsmunoz

-- 
Frederico Muñoz
fsmunoz@gesal.org