[SmartcardServices-Dev] Proposal for patching and maintaining the main source repository

William Siegrist wsiegrist at apple.com
Tue Jul 21 13:15:03 PDT 2009

On Jul 21, 2009, at 10:19 AM, Ludovic Rousseau wrote:

> 2009/7/21 William Siegrist <wsiegrist at apple.com>:
>> On Jul 21, 2009, at 8:38 AM, Ludovic Rousseau wrote:
>>> 2009/7/10 William Siegrist <wsiegrist at apple.com>:
>> Yes, I can create the initial plist. The "scs" was used in this  
>> example
>> since the Mac OS Forge project is "Smartcard Services", but the  
>> name of the
>> plist does not matter. Though, it should not match one of the built- 
>> in
>> plists which are named after build numbers (9G55.plist, 9J61.plist,  
>> etc).
>> The plist can contain all 3 projects, or each sub project can have  
>> their
>> own. I think having 1 plist is easier, but I'm not the one doing the
>> development.
> I vote for 3 different plist files.
> I plan to propose (independent) upgrades for SmartCardServices and
> SmartcardCCID. And I would like to keep the projects independent.
> Maybe a global plist can "include" the 3 other ones?


>>>> Note that this method does not use the source in the subversion  
>>>> repo.
>>>> What could happen periodically is all of the patches get applied  
>>>> to the
>>>> subversion repo and a new tarball is generated. Then the plist is  
>>>> modified
>>>> to point to the new tarball and no patches.
>>> Working directly with subversion would be great. But it looks like  
>>> it
>>> is difficult :-(
>> Thats the conclusion John and I came to as well.  But after some  
>> thought, I
>> believe we could use an svn working copy inside the BuildRoot. So  
>> instead of
>> an initial "darwinbuild SmartCardServices" to download the tarball  
>> and
>> patches, you do a "svn co ..." then the usual "darwinbuild - 
>> nosource ...".
>> I'll have to test my idea first, but if it works, I'll post a new  
>> example
>> workflow that would allow directly committing to svn.  This might  
>> even
>> eliminate the need for a custom plist, as long as you don't need to  
>> modify
>> what dependencies are in the standard 9J61.plist.
> That would be great.

Using svn directly works, but it is still a little cumbersome.  
Darwinbuild does not really support this sort of usage, but this is  
what it would look like for SmartCardServices and Tokend:

$ mkdir ~/scsleo && cd ~/scsleo
$ sudo darwinbuild -init 9J61
... watch darwinbuild fetch plists you need ...
$ sudo darwinbuild SmartCardServices
... watch it load all the roots you need ...
... watch it generate the build scripts and build the stock 9J61  
project ...

# replace 9J61 SCS with checkout from svn
$ cd BuildRoot/SourceCache/SmartCardServices/
$ rm -rf SmartCardServices-34733
$ svn co http://svn.macosforge.org/repository/smartcardservices/trunk/SmartCardServices 
$ cd ../../..

... edit files inside your working copy as needed ...

# try to build your changes
# using -nosource is important as it tells darwinbuild to not   
overwrite your changes to the source cache
$ darwinbuild -nosource SmartCardServices
... watch it build your modified source ...
... edit more files, repeat as necessary ...

# commit or create your patchfile
$ cd BuildRoot/SourceCache/SmartCardServices/SmartCardServices-34733/
$ svn ci . -m 'commit message here'
... or ...
$ svn diff > ~/my_scs_patch.diff

Non-committers would submit patches in tickets and someone would apply  
them when approved. Committers just commit from their working copy.  
You can keep reusing this environment, editing files, updating the  
working copy as others commit changes, etc. So all the steps up to the  
"darwinbuild -nosource" line are a one time setup.

The SmartCardCCID project is not a project in the built-in darwinbuild  
plists. You'll need a plist for people to download and use with  
"darwinbuild -init", and a tarball of the source on the server  
somewhere.  I can bootstrap this for you.

How does this look?


More information about the SmartcardServices-Dev mailing list