On 10/20/03  Jason Stubbs wrote:

> On Monday 20 October 2003 20:12, Marius Mauch wrote:
> > On 10/20/03  Joachim Breuer wrote:
> > > Now, my question is: Shouldn't fixpackages 'stabilize', i.e. not
> > > perform global updates it has already performed? The way it is now
> > > I'd hate to think what an upgrade will be like a year or two from
> > > now... If this 'stabilizing' cannot be done I'd like to know for
> > > what reason, perhaps I'd want to take a look whether there really
> > > isn't an useful optimization.
> >
> > Well, there are different opinions on that. I'd like to make the
> > fixpackages script behave the same way as FEATURES="fixpackages",
> > but there is a reason not to do this: the do_upgrade function which
> > actually does all the work for fixpackages (and more) maintains a
> > mtime table when it runs, but it is run by emerge and fixpackages.
> > The problem now is that when do_upgrade runs from emerge without
> > FEATURES="fixpackages" it updates the mtime table, that means the
> > information would be wrong for fixpackages. I guess in the end we
> > will have to add another mtime table for fixpackages to fix this
> > issue.
> 
> I hate to sound lame, but I'm not sure I followed that correclty.
> fixpackages, when called using FEATURES, only fixes the packages that
> the emerge process touches? And, when calling fixpackages directly, it
> processes all packages? Is that correct? If not, can you please
> explaing the difference between the two?

No, both versions touch all packages, the difference is that the
FEATURES thing will only use updates files (in
/usr/portage/profiles/updates) that were changed since the last run
while the fixpackages script always uses all update files for the
reasons I outlined above.

Marius

-- 
Public Key at http://www.genone.de/info/gpg-key.pub

In the beginning, there was nothing. And God said, 'Let there be
Light.' And there was still nothing, but you could see a bit better.