[gentoo-portage-dev] RFC: Handling of slot operator rebuilds

[gentoo-portage-dev] RFC: Handling of slot operator rebuilds

[Sebastian Luther]

Hi all,

bug 490350 [1] brought me to think about the way rebuilds are currently
handled/can be influenced.

When a new version of some package is about to be installed in the same
slot as the installed version and this new version has a different sub
slot then I see 3 different things one can do:

a) Install the new version and rebuild everything that has a slot
operator dep on it. (The current default.)

b) Skip the update and skip all rebuilds. (You might be able to do this
using --exclude)

c) Perform the update, don't rebuild anything (rely on preserved-libs,
revdep-rebuild). This is --ignore-built-slot-operator-deps=y.

Note that a) and b) are safe things to do, while c) has the potential to
break stuff.

I'd expect that what the user wants, generally depends on the context.
For "-uDN world" I'd expect a), but for "emerge foo" I'd expect b)
unless foo is the update I was talking about. In the latter case I'd
expect a) or c).

Before I continue, I'd like to know if you agree with my analyses. Am I
missing something?


Sebastian


[1] Bug 490350 - sys-apps/portage: Extended user interface of
--ignore-built-slot-operator-deps=y
URL: https://bugs.gentoo.org/show_bug.cgi?id=490350

Re: [gentoo-portage-dev] RFC: Handling of slot operator rebuilds

[Brian Dolbec]

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

On Wed, 2013-11-27 at 12:55 +0100, Sebastian Luther wrote:
> Hi all,
> 
> bug 490350 [1] brought me to think about the way rebuilds are currently
> handled/can be influenced.
> 
> When a new version of some package is about to be installed in the same
> slot as the installed version and this new version has a different sub
> slot then I see 3 different things one can do:
> 
> a) Install the new version and rebuild everything that has a slot
> operator dep on it. (The current default.)
> 
> b) Skip the update and skip all rebuilds. (You might be able to do this
> using --exclude)
> 

You might be able to do this for simple merge lists, but could be
problematic for lists that include pkg updates with blockers or dep
updates.  Where foo, causes rebuilds, but also  includes dep updates
that block/break the installed version of foo.  I would think that if
portage kept the list of pkgs causing the rebuilds, they might be able
to be added to the exclude list without restarting.  But portage may
have to begin the dep calcs again anyway to prevent possible breakage.

> c) Perform the update, don't rebuild anything (rely on preserved-libs,
> revdep-rebuild). This is --ignore-built-slot-operator-deps=y.
> 
> Note that a) and b) are safe things to do, while c) has the potential to
> break stuff.
> 
> I'd expect that what the user wants, generally depends on the context.
> For "-uDN world" I'd expect a), but for "emerge foo" I'd expect b)
> unless foo is the update I was talking about. In the latter case I'd
> expect a) or c).
> 
> Before I continue, I'd like to know if you agree with my analyses. Am I
> missing something?
> 
> 
> Sebastian
> 

I don't think you missed anything.  In that latter case if the user uses
the --ignore-* options they get to pick up the pieces.

> 
> [1] Bug 490350 - sys-apps/portage: Extended user interface of
> --ignore-built-slot-operator-deps=y
> URL: https://bugs.gentoo.org/show_bug.cgi?id=490350
> 




[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 620 bytes --]