[gentoo-dev] Stupid question regarding 'fixpackages'

[gentoo-dev] Stupid question regarding 'fixpackages'

[Joachim Breuer]

Hello!

Just something I notice here: Whenever I run fixpackages, all global
updates are apparently re-applied to all binary packages (i.e. all
headings 3Q-2002 up through 4Q-2003 are shown - in order by now - all
followed by a number of dots which seems to correspond to the number
of operations listed in the update file, and followed by a number of
asterisks which seems to correspond to the number of binary packages.

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.

To clarify the scenario:

I 'emerge sync && emerge -ubkD system && emerge -ubkD world &&
fixpackages' on 2003/08/10, and see the update 3Q-2002 through 3Q-2003
applied. Today I run the same command line again to bring my system up
to date, and see the updates 3Q-2002 through 3Q-2003, which have
already been applied to all binary packages on 03/08/10 being applied
again. Shouldn't it be sufficient to only apply 4Q-2003, or at least
only those updates that have been modified since 03/08/10? (mtime
of /usr/portage/profiles/updates/*)

Is what I'm seeing the current correct behavior, or does for some
reason a time-stamp file on my system not get updated?

Trimming down the number of binary packages is not really an option,
as I (1) like to quickly 'fall back' on an early version of a package
if there turn out to be problems and (2) share virtually the same
gentoo installation over a number of machines with identical
architecture, so usually I let one of the little-used machines do the
ebuilds and let emerge simply install the binary packages on the other
machines.


Thanks a lot for any comments, and kudos for providing *the* useable
distribution!


So long,
   Joe

-- 
"I use emacs, which might be thought of as a thermonuclear
 word processor."
-- Neal Stephenson, "In the beginning... was the command line"

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Stupid question regarding 'fixpackages'

[Marius Mauch]

[-- Attachment #1: Type: text/plain, Size: 1209 bytes --]

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.

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.

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Stupid question regarding 'fixpackages'

[Joachim Breuer]

Marius Mauch <genone@gentoo.org> writes:

> 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.

Ah! Allright, thanks for clarifying that. So, can I expect better
over-all performance if I put 'fixpackages' into my FEATURES, and no
longer need to use the fixpackages script then?


So long,
   Joe

-- 
"I use emacs, which might be thought of as a thermonuclear
 word processor."
-- Neal Stephenson, "In the beginning... was the command line"

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Stupid question regarding 'fixpackages'

[Marius Mauch]

[-- Attachment #1: Type: text/plain, Size: 614 bytes --]

On 10/20/03  Joachim Breuer wrote:

> Ah! Allright, thanks for clarifying that. So, can I expect better
> over-all performance if I put 'fixpackages' into my FEATURES, and no
> longer need to use the fixpackages script then?

Depends on how often you used to run fixpackages: if you've run it
everytime emerge told you FEATURES="fixpackages" is better, if you only
run it once per month I'd stick with the script.

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.

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Stupid question regarding 'fixpackages'

[Jason Stubbs]

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?

Regards,
Jason

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Stupid question regarding 'fixpackages'

[Marius Mauch]

[-- Attachment #1: Type: text/plain, Size: 1966 bytes --]

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.

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]