[csw-pkgsubmissions] newpkgs dialog

Ben Walton bwalton at opencsw.org
Sun Feb 13 01:58:29 CET 2011


Excerpts from Jonathan Craig's message of Sat Feb 12 15:14:59 -0500 2011:

Hi Jonathan,

> > (by having a shared instance of GAR.. ideally as package, installed on
> > the buildfarm, so everyone is always automatically on the same version
> > of GAR, if memory serves me correctly)
> 
> Not sure if a common tree is the best answer as it hampers ones
> ability to work / test out other recipes while learning.  That aspect
> of a private tree has been very helpful to myself as a new
> maintainer.

In past discussions, we've talked about making just the GAR code a
standalone, shared entity, delivered as a package.  The build recipes
would still be private to your own checkout.

I still think this is ultimately a good idea, but there are things
that have prevented anyone from tackling it.  Not the least of these
is the frequency of the updates to GAR[1].  It's constantly being
improved in various ways and that would leave to a pile of updates on
the build boxes.

Sebastian's new tool 'mgar' in conjunction with a per-machine shared
checkout of gar/v2 may be a good compromise.  I think he's planning to
demo it at the camp next week and maybe expose it to wider use after
that.  Several of us have been using it with good results so
far...things may be looking up in this regard.  (I hope I'm not
putting you on the spot Sebastian!)

>  That said, it is easy to forget to update your private copy of gar.
> I would think a check during the make process that stops your build
> with a message if your using an older revision of gar would be
> helpful.  You could then have a variable that allows a maintainer to
> proceed in the case where a maintainer intentionally wishes to use
> an older rev of gar (ie GAR_SKIP_VERCHK).

Anything that incurs a subversion round trip to sourceforge every time
a gmake target (or at least once per 'spotless') is triggered would
quickly drive me to set that variable.  Subversion is just to slow to
inline that process in my opinion.  If we were working with a faster
tool or more local network, this would be more viable.

Ultimately, we're just in the habit of frequently updating our trees.
Mostly, you can get away with not doing this frequently, Phil just got
behind an actual bug in this particular instance.

It would be nice to have a shared GAR instance

Thanks
-Ben

[1] I seem to recall this being considered a flaw, but I see it as a
    boon...we're actively improving the tool on a regular basis.
--
Ben Walton
Systems Programmer - CHASS
University of Toronto
C:416.407.5610 | W:416.978.4302



More information about the pkgsubmissions mailing list