Re: GNUstep packaging by TWW tools

[T.J. Yang]

> From: Richard Frith-Macdonald <address@hidden>
> To: T.J. Yang <address@hidden>
> CC: address@hidden
> Subject: Re: GNUstep packaging by TWW tools
> Date: Wed, 27 Dec 2006 10:59:51 +0000
>
>
> On 26 Dec 2006, at 20:02, T.J. Yang wrote:
>
> > My plan
> > 1. prepare gcc-4.1.1 for Solaris 10 intel (U2, 06/2006 version)  first and 
> > down port lower version solaris and sparc cpu.
>
> This is fairly straightforward ... I've done it for 32 bit and 64bit  
> solaris ... you shouldn't have any trouble.

Great, would you mind to try out gcc-4.1.1 for GNUstep ?
Currently I have 4.1.1 for Solaris 10 intel, it can compile helloword.m
but it failed the configure script when compiling gnustep-base.
looks like I need to relocate objc/objc.h to a path that can be found.



> > 2. package the gnustep core software(make,base,gui).
>
> I don't know CPAM at all ... but I've packaged these things using  solaris 
> native packaging (pkgmk etc) and a cursory scan of the pages  at 
> http://en.wikibooks.org/wiki/CPAM_with_TWW/User_Guide suggests  that CPAM 
> acts as a layer on top of pkgm, so it ought to be workable.

TWW's CPAM is an evolution not a revolution solution like OpenPKG.
Existing knowledge of native packages still needed and depended upon.
It make abstract software build process into a repeatable XML format.
when building SVR4 package, TWW's pb tool will call up pkgmk to make
the SVR4 package and if pb runs on RH Linux, then it will call up rpmbuild 
to
build the package.


> > 3. release package sources
>
> You will need to make a copyright assignment to the FSF to get the  
> packaging source incorporated into the projects.
> See http://mediawiki.gnustep.org/index.php/ 
> Developer_FAQ#How_do_I_assign_my_contribution.3F
>
> > 4. Lobby gnustep development community to use TWW tool so
> >   TWW CPAM tool can help GNUstep's CPAD.
> >   This will be hard because asking people to switch to different  tools 
> > using
> >   different processes.
>
> I don't know CPAM details, but if it produces a wrapper round a  'native' 
> package format, such that the native package is still  available, I expect 
> there would be no resistance as it would allow us  to build (and therefore 
> provide easily on the ftp site) both the  native packages and the 
> higher-level CPAM packages.
> If on the other hand, it results in something which can only be  installed 
> with the CPAM installer, I expect it would be argued that  we should just 
> build packages in the 'native' formats, so that they  can be installed 
> without the need to download/use the CPAM tool.

TWW package format is in "pkg-inst" format which is a zipped file/directory 
of
native packages in native format. One can certainly unzip the TWW packages 
format
into native ones and use pkgadd to do package installation.

The downside is that the auto installation of depended software will then 
need
to be installed manually.

> One issue though ... the list of supported operating systems for HPMS  does 
> not include ms-windows ... the whole point of this system is to  wrap all 
> other systems inside a single toolset, but if it omits what  is arguably 
> the second most important target operating system, then  it's probably not 
> actually very useful.
> I think it's therefore important to find out whether ms-windows  support is 
> available, or under development and near enough complete  for you to join 
> in and perfect it.  If ms-windows support is  available then this sounds 
> like a very good idea.


Correct, TWW tools for win32 is not ready yet but this doesn't prevent 
GNUstep
(for Unix) to adopt the TWW tools.

TWW tools(and all the software they packaged) are in GPL license so if an OS 
is not
supported, we can port the tools over.

I tried to port the tools to Linksys nslu2, Mac OS X and win32 with some 
progress
but I reach my limit of ability and time.(Now you know I have these three OS 
at home ;).

for TWW and win32, here is my finding and testing

sb(software build) tool was ported over quite easily using cygwin.
pb(package build) tool need more thinking because there so many PMS
solutions for win32. Personally I favor WiX becuase it use xml file for 
describing
package building and it is from vendor(MS). Using WiX will make pb wrapper
much easier, it will be just TWW's XML converted to WiX's XML format.

currently gnustep win32 is not using WiX for packaging, I hope this can be 
changed
to use WiX. when TWW tools for win32 is ready, the conversion to use TWW 
will
be easier.

Regards


tj


>

_________________________________________________________________
Find sales, coupons, and free shipping, all in one place!  MSN Shopping 
Sales & Deals 
http://shopping.msn.com/content/shp/?ctid=198,ptnrid=176,ptnrdata=200639