On 9/12/07, Iain Buchanan <[EMAIL PROTECTED]> wrote:
> On Wed, 2007-09-12 at 18:06 -0700, Mark Knecht wrote:
>
> > Sorry. I should have started that a number of the failures have come
> > while doing revdep-rebuild. One seemingly large problem is that
> > revdep-rebuild wants to rebuild packages that are no longer in portage
> > so you have to remove those from the rebuild or attempt to change
> > revision numbers by hand on the fly in the long command that
> > revdep-rebuild -p creates. That's been a mess and not the way I know
> > the portage developers want me to maintain the system.
>
> -X, -X, again I say -X!
>
> with ~x86 revdep-rebuild, this behaviour is default, but most likely
> with your revdep-rebuild, you can specify -X to get the latest version
> of the packages.  Otherwise it will try and use the currently installed
> version, which isn't what you want when in the middle of a large
> upgrade!
>
> HTH,
> --
> Iain Buchanan <iaindb at netspace dot net dot au>
>

That's very interesting. What about slotting issues? What if it's the
old version in a slot that needs to be rebuilt? (FYI - I don't really
understand slotting that much since I don't program. I've guessed it's
because some code needs old libraries, etc., and somehow slotting
takes care of that.) Does -X install the latest version in the
specific slot?

Anyway, I've wondered at times about just removing all the specific
revision numbers but I'm wary of going beyond my comfort zone and then
ending up in a state that's more difficult to fix.

Maybe the revdep-rebuild guys should (could?) include -X if it's the
right thing to do?

Thanks for the info.

- Mark
-- 
[EMAIL PROTECTED] mailing list

Reply via email to