Ticket #1312 (closed enhancement: invalid)

Opened 6 years ago

Last modified 4 years ago

mismatched sub-slots don't trigger rebuilds of dependant packages

Reported by: hasufell Owned by:
Priority: Sometime Milestone:
Component: clients/cave Version: 2.0.0
Keywords: Cc:
Blocked By: Blocking:
Distribution: Gentoo

Description

Gentoo PMS says "The sub-slot is used to represent cases in which an upgrade to a new version of a package with a different sub-slot may require dependent packages to be rebuilt"

So, unless I missed something it seems paludis just considers these plain blockers. That means, for a world update where we have like 20 subslot changes you will get >300 blockers and have one of these choices:

  • figure out all of them manually and force their deps to be rebuilt via -D (takes a lot of time and will have tons of false-positives)
  • force installation of the packages that have changed subslot, then grep the VDB for packages that depend on the old subslot and rebuild them manually (dangerous and time consuming)
  • just rebuild everything unconditionally... (no one wants this)

None of these solutions are user friendly, nor does it reflect the purpose of subslots as outlined in PMS.

So, paludis should be able to pull in packages for rebuild if there is such a subslot mismatch (maybe via a --switch, see below). If the ebuild has ":=" or similar, then there will be no blocker.

I personally don't even care much about subslots, so another thing to consider would be an option to ignore them altogether and rely on 'cave fix-linkage' instead.

So maybe something like (just a proposal): Subslot Options

Control how subslots are treated -Z

rebuild-dependants (r)

If subslots from installed packages mismatch subslots from packages already in the dep graph, then trigger a rebuild for those. (default if --complete or --everything)

no-rebuild-dependants (n)

Don't treat subslots special. Mismatches will result in blockers. (default)

ignore-subslots (i)

Don't use the subslot information for matching dependencies. Make sure to use 'cave fix-linkage' when using this. (default if --lazy)

I'm not sure how complicated it would be to implement -Zr cleanly or if it's even possible, but -Zi should be fairly straight forward I guess.

Change History

comment:1 Changed 6 years ago by hasufell

This should be for version 2.0.0, but trac does not show it.

comment:2 follow-up: ↓ 4 Changed 6 years ago by ciaranm

It's not about blockers at all. The issue is installed packages that aren't being changed, that are locking a subslot to its existing value. If you've got an installed package that isn't being upgraded that requires foo/bar-1.23, we won't upgrade foo/bar to 1.24.

comment:3 Changed 6 years ago by ciaranm

  • Version changed from 1.4.2 to 2.0.0

comment:4 in reply to: ↑ 2 Changed 6 years ago by hasufell

Replying to ciaranm:

It's not about blockers at all. The issue is installed packages that aren't being changed, that are locking a subslot to its existing value. If you've got an installed package that isn't being upgraded that requires foo/bar-1.23, we won't upgrade foo/bar to 1.24.

Sure, I know how they are recorded in the VDB. With blockers I meant "unsuitable candidates" warnings which cause you to fix it manually.

So, especially if you want to update dev-lang/ghc you will get a shitload of these warnings since the subslot is $PV. In the case of ghc it even makes sense to use "-D", but that's not always the case and still requires you to read through all the error messages.

comment:5 Changed 5 years ago by torotil

subscribe -- IMHO with increasing use of subslots in gentoo this becomes a blocker.

comment:6 follow-up: ↓ 7 Changed 4 years ago by L29Ah

This is becoming quite sad as i have to hunt for those error messages every other day, mainly from haskell libraries updates. How does portage handle this?

comment:7 in reply to: ↑ 6 Changed 4 years ago by hasufell

Replying to L29Ah:

How does portage handle this?

It pulls in all packages with a subslot mismatch into the dependency graph. Paludis just tells you there IS a mismatch and then stops, which doesn't give sufficient control to the user on how to handle that.

comment:8 Changed 4 years ago by ciaranm

  • Status changed from new to closed
  • Resolution set to invalid

Closing this off because it keeps confusing people who don't understand why cave does exactly what they tell it to do.

comment:9 Changed 4 years ago by L29Ah

Check out this awesome kludge i wrote:

#!/bin/sh
f="`mktemp`"
cave "$@" | tee "$f"
grep -q 'I encountered the following errors:' "$f" && {
	atoms="`sed -r "s/\x1B\[([0-9]{1,2}(;[0-9]{1,2})?)?[m|K]//g" "$f" | sed -ne ':1;/^!   /{x;bq};/\/[0-9][0-9.]*=/{x;p;b1};:q' | uniq | sed -e 's#!   ##'`"
	for a in $atoms; do
		append="$append -D $a"
	done
	echo "$0" "$@" $append
	"$0" "$@" $append
}
rm "$f"
Note: See TracTickets for help on using tickets.