On two machines openshot-2.5.1 was installed (and working properly). When trying to upgrade these machines icu was reported as being skipped. This affected all other packages that depend on icu, e.g. qtwebkit, boost and so on. openshot itself was not scheduled for update since keyword ~amd64 prevents this. So both machines were left with large packages/ update times ahead since the large packages a distributed there as binaries. But the binary host already bumped to icu 70 not being affected by openshot constraints. Reproducible: Always Steps to Reproduce: 1. Have a machine with openshot-2.5.1 installed 2. update 3. icu 70 reported as skipped Actual Results: Large portions of world update blocked due to icu pinned to 69 and/ or binary packages rejected due to changed dependencies. The latter is the most annoying since tracking it down to openshot is very hard. Expected Results: Some news (eselect news read) or hint regarding effects with a basic library like icu (pinned through openshot to 69 affecting an important set of system-packages and others build atop.) Can be easily resolved by: 1. removing any USE on behalf of openshot from /etc/portage/package.use, esp. PyQt5, qtmultimedia, ffmpeg and/ or zeromq 2. add keyword ~amd64 for openshot, libopenshot and libopenshot-audio 3. add recommended USE-flags again as suggested by emerge --update @world/ openshot Requires also --deep and --with-bdeps=y or otherwise @preserved-rebuild afterwards.
I think the issue is more that Portage doesn't always tell you when an installed package can't be upgraded due to keyword visibility. A news item wouldn't have helped as issues like this can happen all the time with various packages. (FWIW: something like: emerge -p -e --backtrack=0 @world is good at showing these issues, but I agree you shouldn't have to do this.) *** This bug has been marked as a duplicate of bug 372005 ***
(In reply to Sam James from comment #1) > > A news item wouldn't have helped as issues like this can happen all the time > with various packages. Might be true from your point of view. I appreciate and read all the news items and also follow the suggestions. If this is a common problem a news item could be auto generated. My main point was that a rather rarely used package like openshot pinned icu affecting the entire context (due to binary packages and their dependencies spreading across multiple machines). I wasted 4 working hours and 16hrs re-building qtwebengine 3,75 times. Lets add those few openshot users who have to search through the web when they end up here. And since you are already aware of the general failure in such cases wouldn't it make sense to think about the flaw and find a solution? Shouldn't software be a help? (No offence and not personal but rhetoric to start a sort of planning to improve portage on that. I've already been down the rabbit hole with warning regarding changed dependencies when binary packages get rejected which I shortened to parse Packages-file and search patterns I came across in the past.) Other packages like ufraw were also announced when being removed. Recently rust got blocked or the broken preserved libraries. With the latter I maybe saved 5 machines from possible harm with 1-2 findings per machine. If it is a matter of writing time: I'll do it. > > (FWIW: something like: emerge -p -e --backtrack=0 @world is good at showing > these issues, but I agree you shouldn't have to do this.) > I already run some pre-checks, e.g. estimation of build time/ large chunks/ major number upgrades of important packages. I'm planning to add such silent exclusions, too. Should be something like: For all ebuilds of world file there must be no version in the repository that is the only version and requires accept keywords and is different from the installed version. (=fast pre-check, peano principle/ 80% rule) I also thought about matching all installed ebuilds' dependencies if exact version required against a list of fundamental ebuilds. (boost, icu, ncurses, gtk+, ... = academic approach)
(In reply to onkobu from comment #2) > (In reply to Sam James from comment #1) > > > > A news item wouldn't have helped as issues like this can happen all the time > > with various packages. > > Might be true from your point of view. I appreciate and read all the news > items and also follow the suggestions. If this is a common problem a news > item could be auto generated. > I'm saying it would not be possible to create a news item for every single package which has a subslot dep on another when the subslot is bumped, and it'd be noise for most people. Especially given we could have similar problems with e.g. licence missing anyway. And we don't have a way of only showing this when someone is missing the needed entry in e.g. package.accept_keywords. News items for stuff like this would mean people are even less likely to read them as it'd _rapidly_ increase the pace & amount of news items. > My main point was that a rather rarely used package like openshot pinned icu > affecting the entire context (due to binary packages and their dependencies > spreading across multiple machines). My suggestion is to not put exact pins in package.accept_keywords. > > I wasted 4 working hours and 16hrs re-building qtwebengine 3,75 times. Lets > add those few openshot users who have to search through the web when they > end up here. > > And since you are already aware of the general failure in such cases > wouldn't it make sense to think about the flaw and find a solution? > Shouldn't software be a help? (No offence and not personal but rhetoric to > start a sort of planning to improve portage on that. I've already been down > the rabbit hole with warning regarding changed dependencies when binary > packages get rejected which I shortened to parse Packages-file and search > patterns I came across in the past.) > I did think about the flaw, hence why I marked as a duplicate of another one, and gave suggestions. I don't think I have the familiarity enough with the Portage codebase yet or enough time to try dig into fixing this fully. I think we could at the very least try notify when installed packages couldn't be re-built due to keywords somehow though. I _suspect_ this won't be too hard. (And yeah, for binpkg hosts, people often use --changed-deps for this, although they shouldn't have to.) I do not know what more I can do right now. If you are able to try poke at the Portage code, that'd be a big help. > Other packages like ufraw were also announced when being removed. Recently > rust got blocked or the broken preserved libraries. With the latter I maybe > saved 5 machines from possible harm with 1-2 findings per machine. > Please file bugs for preserved-libs issues where there's a := missing from ebuilds! But right, nothing here got removed, it was just that because there was a pinned version in p.accept_keywords (or installed one-off on command line), Portage rightly thought it wasn't allowed to install it (again) to satisfy the needed rebuilds. Related is --autounmask-unrestricted-atoms.
