[csw-pkgsubmissions] newpkgs cmake

Dagobert Michelsen dam at opencsw.org
Thu Nov 11 09:13:06 CET 2010


Am 10.11.2010 um 23:37 schrieb Sebastian Kayser:
> rupert THURNER wrote on 10.11.2010 22:19:
>> On Wed, Nov 10, 2010 at 10:17, Sebastian Kayser  
>> <skayser at opencsw.org> wrote:
>>> Maybe Rupert hasn't updated his gar/ tree yet? How about integrating
>>> some sort of gar/ revision information in the pkginfo file so that  
>>> this
>>> becomes visible in general?
>>> I am not quite sure how this would best be done though, as there  
>>> is no
>>> single GAR revision but a collection of files with different  
>>> revisions.
>>> Thoughts (besides switching from a moving gar/ target to versioned  
>>> GAR
>>> releases)?
>> rupert is updating the gar tree before running a build
> Ruper is a role model ;) I fell into that trap more than enough  
> myself,
> that's why I pointed it out. No offense intended.
>> and there is
>> also a unique id, the subversion "revision" :) e.g. go direct to some
>> file in the gar folder in case there is a symbolic link to gar:
>> $ svn info gar/categories
>> Path: gar/categories
>> URL: https://gar.svn.sourceforge.net/svnroot/gar/csw/mgar/gar/v2/categories
>> Repository Root: https://gar.svn.sourceforge.net/svnroot/gar
>> Repository UUID: d3b55034-1cff-0310-a425-aefe953e1e90
>> Revision: 11556
>> Node Kind: directory
>> Schedule: normal
>> Last Changed Author: dmichelsen
>> Last Changed Rev: 11547
>> Last Changed Date: 2010-11-10 09:04:13 -0600 (Wed, 10 Nov 2010)
> So if one calls "svn info gar/" and reads the Revision: that's the
> latest revision of any file that currently sits beneath the locally
> checked out gar/? A revision which could then be embedded into pkginfo
> by GAR to reference the employed point-in-time-copy of gar/?

Well, my initial thought was if a releasable version is going to be
made a snapshot of trunk is done to tags/<software>-<revstamp> and
the external reference to GAR is changed to point to the fixed
version at the time of snapshot. The package build would then
include the SVN URL to the snapshot allowing specific tracking of
the GAR rev by looking at that external reference.

However, I always postponed that step as it makes most sense with
an automated build and would also benefit largely from the changed
release model we discussed during the camp as built packages would
automatically go into an experimental repository and submitpkg
would migrate from there to unstable.

Funny to see how all things are connected...

Best regards

   -- Dago

More information about the pkgsubmissions mailing list