1 |
Hey, |
2 |
|
3 |
Ed W wrote: |
4 |
>> I wouldn't have mentioned an IP lawyer at all had it not been for the |
5 |
>> fact that I know that you are in the US. :) |
6 |
> |
7 |
> I'm in the UK |
8 |
|
9 |
Ha! Awesome. :) Sorry, must have mixed you up then! |
10 |
|
11 |
|
12 |
>> I use catalyst, and I control what gets deployed with custom ebuilds |
13 |
>> and snapshots. The fewer packages in the final system the better; |
14 |
>> less stuff to track. |
15 |
> |
16 |
> Whilst I guess it should be possible to tear apart catalyst and find out |
17 |
> how they do it, does anyone happen to know or have a heads up on the code |
18 |
> for catalyst? |
19 |
|
20 |
The catalyst code has no part in this, but it takes a portage snapshot |
21 |
as one of it's inputs, and if you maintain a custom snapshot (with |
22 |
only packages you need) then you know what gets used. |
23 |
|
24 |
|
25 |
> It must be a solved problem so I should think others have solved |
26 |
> this in various ways? |
27 |
|
28 |
I'm not sure it is a solved problem. If you want a different solution |
29 |
than basically maintaining your own portage snapshot then the easiest |
30 |
way to track patches is (third time now) to add bookkeeping in the |
31 |
epatch function. |
32 |
|
33 |
|
34 |
//Peter |