[OGo-GNUstep-Port] Re: gstep-make upgrade

[Helge Hess]

Hi,

I took gnustep-port into CC, hope you two don't mind!

On Montag, 28. Juli 2003, at 17:31 Uhr, Tony Clayton wrote:
> I've discussed the GNUstep-reset.sh script (one of the patches I just
> submitted to patches@) with Nicola, and he suggested that it would be
> better to stay up-to-date with the latest gstep-make package (he
> believes that script is already fixed in the latest).
>
> This sounds like a good plan.  The latest gstep-make is 1.7.2, which
> is marked as "unstable", but what better way to make it stable then to
> throw OGo at it ;).

My standpoint regarding is: it would be great if OGo would always work 
against the latest gstep-make, but this should in no case break 
compatibility with the gstep-make checked into OGo which is used for 
deployment.

GNUstep-make wasn't very stable (from an API point of view) in the 
past, the directory structure changes every other month and this simply 
isn't acceptable for a project like OGo. We can track that once a year 
or so, but not in the speed gstep-make moves forward.
Personally I also do not have the impression that this is really 
necessary, the gstep-make in OGo works just fine and smaller backward 
patches are easy to do. I rather do that instead of tracking a version 
all the time.

> If no one else is currently doing this, I'd like to try and get OGo
> using pristine gstep-make sources (and perhaps others to follow).

I think for development environments that should work without big 
problems. It's for deployment setups where OGo gstep-make has some 
patches.

> Also, I'm not sure what you are doing wrt the ThirdParty cvs modules,
> but I've found the following approach good for keeping up with the
> latest sources:
>
> - create a separate cvs module for each third-party package (like
> 		gstep-make)

Hm, why? What additional values is given to you by a separate CVS 
module? We also thought about that prior setting up OGo CVS, but 
couldn't find a reason for not using the same CVS module.

> - import and tag the pristine sources with the third-party versions

We track changes in the ChangeLog or ChangeLog.skyrix (could be renamed 
to ChangeLog.OGo), if the project already has one.

> - apply any changes/patches on top of this
> - create distro packages (ie: rpms) by including the pristine source
>   tarball from the third party, plus patches diff'd from CVS
> - you can use the CVSROOT/modules file to create a "virtual" cvs
>   module containing the entire OGo tree, but still have all the
>   modules in separately

Packaging isn't related to that at all. The RPM/Deb building is based 
on .tgz archives which do not need to come out of CVS.

> This is how I will be setting it up on my end for the initial
> forward-port.  I'll provide scripts and/or logs of what I do in cvs,
> and perhaps they might be useful for the OGo project.

Again, I don't think anything really needs to be "ported" to 
gstep-make, it should work pretty much out of the box. If you find 
issues, let me know ;-)

regards,
   Helge
-- 
OpenGroupware.org	- http://www.opengroupware.org/