Re: A stupid package script to feed an installer

[Frederico Muñoz]

On 2005-02-16 18:56:23 +0000 comrade@loki.rcpt.to wrote:

> Hi
> 
> I was thinking about the whole binary distribution thing for GNUstep
> packages, and did a bit of research into Openstep and Cocoa packages.

That's great, this way I can compare with my own research. The NeXT format is 
simple enough, but the OSX one has many, many optional files, locations, 
scripts and steps.

> 
> I've hacked together a half-working packager based on information from
> an Openstep manpage online and a description on another. It's attached to 
> this mail. More than 40% of the script contains comments (moans) on
> what I've found out about this (fairly limited) package format. On the
> other hand it's simple and it works.
> 

Thanks a lot, due to the apparent interest in .pkg I am finishing the bundle 
that handles it. I have made a test GNUstep .pkg of AClock and edited the 
required fields by hand.

> I'm putting it forward - even though it uses pax right now(!) and requires at 
> least a small edit to work on anything other than NetBSD -
> to get some progress on the binary package front. We need gui and
> command-line installers and updaters to make it easy to get into GNUstep
> for new developers and end-users.

The Installer front is on the way, and I would dare say that maybe tomorrow 
Installer.app will be able to at least view and install NeXT formated .pkg. 


> 
> Please fix problems with this little script, generate packages,
> create installers, discuss metadata enhancements and what to do about the
> big missing component, the .bom (bill of materials) binary format,
> undocumented by NeXT and Apple. Is it time to agree on .gnubom?

I was just alking about this on #gnustep. I have been for a while trying to 
find anything about the format, and it's a complete dead end. Not a shred of 
information on what it is. I am for the time being using a very simple format 
that is the output of "find . -printf "%m %s %U:%G %c %p\n"   ". The BOM format 
is probably more than this, since it probably also contains, or contained, 
information for MAB packages about what platforms were supported, etc.

I also added a "AClock.copyright" file to get the licence, since I think it's 
missing from NeXT format. OSX format includes something to that effect.

I must stress that my initial aim is to simply provide the minimum necessary 
information. This should be sufficient for the current aim and will no doubt 
facilitate binary distribution (outside of the native package management 
options, that should of course be supported). I can add support to more 
metadata, but the format and the quantity of that should be discussed. One easy 
route is to mimic more or less the external aspexts of the OSX package, that 
are based on the NeXT one, but this should be discussed. 

This means that I will gladly support things, but will not make the decision on 
the format alone (if I can help it, at least :) ).


Best regards, and thanks for your script,


fsmunoz

-- 
Frederico Muñoz
fsmunoz@gesal.org