1 |
On Thu, 2008-09-18 at 08:52 -0500, Andrew Gaffney wrote: |
2 |
> Amit Dor-Shifer wrote: |
3 |
> > Is that the way autoresume's intended to work? If so, should I clear |
4 |
> > autoresume points upon every modification in a conf file? |
5 |
> |
6 |
> Catalyst doesn't store any metadata about the spec file for a particular build, |
7 |
> so it has no way to know if the spec has changed. That will probably chance in |
8 |
> the future. For now, just make sure to use -a when you change the spec file. |
9 |
|
10 |
The general rule I use is to use -a if I changed anything that affects |
11 |
dependencies, or if I'm making a change in a section that has already |
12 |
been processed. The autoresume support was really designed to recover |
13 |
from failed merges, rather than to be a robust solution. As Andrew |
14 |
said, I'd eventually like to make the autoresume much smarter, which |
15 |
means we'd likely need to store the spec file in the autoresume data. |
16 |
If the keys in the spec for a particular function has changed and that |
17 |
function has already been run, delete the autoresume for that function. |
18 |
As we make things more and more modular, this could allow for an |
19 |
"autoresume" of a nearly-completed build where only the changes need to |
20 |
be processed. Using your "rcadd" as an example, let's say you were at |
21 |
the point of the ISO being made and realized that you forgot to add a |
22 |
service. You hit CTRL+C, edit the spec, then re-run catalyst, which |
23 |
would see that only the rcadd changed, so it would remove the autoresume |
24 |
data for the rc-update function |
25 |
(targets/livecd-stage2/livecd-stage2-controller.sh) and process only |
26 |
that function and the remaining ones, giving you an ISO with the least |
27 |
amount of processing time. |
28 |
|
29 |
-- |
30 |
Chris Gianelloni |
31 |
Developer |
32 |
wolf31o2.org |