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

[Ludovic Rousseau]

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>:
>>> # download the custom plist with curl or svn
>>> $ curl -LO
>>>
>>> http://svn.macosforge.org/repository/smartcardservices/trunk/plists/scs_leopard.plist
>>
>> I can't find this file. Can you create it?
>>
>> Maybe each sub project (SmartcardCCID  SmartCardServices  Tokend)
>> should have a plists directory and the plist names could be
>> leopard.plist (without the obscure "scs_")
>>
>> Something like:
>> smartcardservices/trunk/SmartCardServices/plists/leopard.plist
>> smartcardservices/trunk/SmartcardCCID/plists/leopard.plist
>> smartcardservices/trunk/Tokend/plists/leopard.plist
>>
>
> 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.

Bye

-- 
 Dr. Ludovic Rousseau