1 |
Brian Harring wrote: |
2 |
> On Thu, Oct 27, 2005 at 11:50:02PM +0900, Jason Stubbs wrote: |
3 |
> |
4 |
>>On Wednesday 26 October 2005 23:56, Jason Stubbs wrote: |
5 |
>> |
6 |
>>>I've attached a quickly thrown together patch for it, which works here, but |
7 |
>>>we really need to get this whole thing down pat. Perhaps usage of doebuild |
8 |
>>>without specifying tree should be deprecated and the code audited for any |
9 |
>>>usage without it? Making tree a keyword parameter will break too many |
10 |
>>>external things so that's not really an option... |
11 |
>> |
12 |
>>Updated patch; I missed a call to merge(). I really don't like this patch |
13 |
>>though because it touches way too much stuff. Anybody have any ideas for a |
14 |
>>better way of doing it? |
15 |
> |
16 |
> Offhand, don't pass mytree around like that; pass it into the |
17 |
> constructor, assign to the obj's namespace, and have treelink pass the |
18 |
> saved value into doebuild. |
19 |
> |
20 |
> That's how I did it in 2.1 at least; been a long while, but don't |
21 |
> recall any major issues with that route. Plus side, heck of a lot |
22 |
> less modification to methods signatures, just the objects behaviour. |
23 |
> ~harring |
24 |
|
25 |
I adapted Jason's patch to go along with the dblink.treetype bit from 2.1 and it seems to work alright. The only notable difference from Jason's patch is that tree=self.treetype is passed into doebuild in any case for preinst and postinst (following the lead of 2.1). |
26 |
|
27 |
Zac |