Summary: | [QA] sys-devel/gcc[-multislot] blockers and upgrade behavior change | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Michał Górny <mgorny> |
Component: | [OLD] Unspecified | Assignee: | Gentoo Quality Assurance Team <qa> |
Status: | RESOLVED FIXED | ||
Severity: | QA | CC: | dilfridge, floppym, gokturk, itumaykin+gentoo, josef64, orzel, proteuss, toolchain, zsojka |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | |||
Bug Blocks: | 582504 |
Description
Michał Górny
2016-05-30 20:43:41 UTC
My vote: Item 1: yes Item 4: abstain Items 2 and 3 are mere suggestions/recommendations, therefore I don't think that we should even vote on them. Well, I was more thinking of voting on all four points as a complete resolution. Though I guess I can reassemble it is necessary. Do you think point 2 needs a stronger wording? The goal was not to force specific 'when to auto-upgrade' on them but disallow the unprepared switch to gcc5. Yes to all 4 points 1/2: yes 3/4 abstain you really should CC the teams in question when discussing changes involving their bugs. if you don't, you really shouldn't be surprised by no one noticing it. as outlined in bug 582504 (which this really is just a dupe of), the multislot behavior isn't a change. it's enforcing historical behavior in a different way (which the QA forced in the first place). if people want to drop that behavior (autocleaning of old versions) and only rely on portage-depclean-esque cleanup, it doesn't matter to me. as for (2), that just shows a lack of understanding of how the code actually works. the eclass has never done this. (In reply to SpanKY from comment #5) > you really should CC the teams in question when discussing changes involving > their bugs. if you don't, you really shouldn't be surprised by no one > noticing it. > > as outlined in bug 582504 (which this really is just a dupe of), the > multislot behavior isn't a change. it's enforcing historical behavior in a > different way (which the QA forced in the first place). if people want to > drop that behavior (autocleaning of old versions) and only rely on > portage-depclean-esque cleanup, it doesn't matter to me. > > as for (2), that just shows a lack of understanding of how the code actually > works. the eclass has never done this. the only thing i don't get is why you had gcc 4.9.3 blocking against itself leading to this: [blocks b ] <sys-devel/gcc-4.9 ("<sys-devel/gcc-4.9" is blocking sys-devel/gcc-4.9.3) the only way people can move past that is to set USE=multislot (at least temporariliy) (In reply to Anthony Basile from comment #6) gcc-4.9 isn't blocking itself: !multislot? ( !<${CATEGORY}/gcc-4.9 ) that is what all the newer ebuilds say and have since the update. that output indicates a bug in portage. (In reply to Michał Górny from comment #0) re-(4), to use your phrasing, i'd remind the QA team that the policy says changes to DEPEND do not require a revbump (which, if you read the change to the ebuilds, was literally 1-line addition to DEPEND). nor is this a "breaking" change as nothing silently changed -- the user had to accept the blockers when building a newer gcc the next time. (In reply to SpanKY from comment #7) > (In reply to Anthony Basile from comment #6) > > gcc-4.9 isn't blocking itself: > !multislot? ( !<${CATEGORY}/gcc-4.9 ) > that is what all the newer ebuilds say and have since the update. > > that output indicates a bug in portage. mike, you're right. this is a bug in portage. let me understand though how this blocker is going to work moving forward. when we're finished stabilizing gcc-5.3.0 across all arches, are we going to update these blockers to block against <${CATEGORY}/gcc-5.3.0 and remove that line from gcc-4.9.3? 1. Nitpicking on the wording isn't exactly helpful. Policies are to be respected in spirit. 2. Having the blocker in DEPEND only is pretty much meaningless and even worse since it affects building binary packages rather than actually installing the gcc. 3. The last point referred to around 80% of commits to toolchain.eclass you did, and wasn't targeted at a specific one.
>
> [blocks b ] <sys-devel/gcc-4.9 ("<sys-devel/gcc-4.9" is blocking
> sys-devel/gcc-4.9.3)
>
mike another point. installing a new version of gcc will uninstall the older version when USE=-multislot. won't this cause problems with executables linking against libraries under /usr/lib/gcc/x86_64-pc-linux-gnu/4.9.3/ ?
(In reply to Anthony Basile from comment #9) correct. once the current stable versions stabilize/settle down, the blockers would pull up to that. so when 5.4.0 goes stable and people are fine, it'd block everything older. and everything older would drop the blocker. (In reply to Michał Górny from comment #10) (1) no idea what you're talking about. perhaps your use of bullet points has you confusing which ones are which. or you started a new list for fun and are now making generalized points even though you asked for feedback on specific things. (2) not really. it enforces the same policy we've had for years at this point in the closet way the QA team would allow w/out throwing a pointless fit. portage also happily ignores things if you pass --nodeps. (3) it's a good thing you're writing it under this bug then. (In reply to Anthony Basile from comment #11) i'm not sure what you're asking about. the blocker is only against gcc-4.8 and older. so if you're using 4.9 and install 5.3, 4.9 isn't going anywhere. ignoring that, gcc libs are backwards compatible. so the only breakage would come if you have a newer gcc built with fewer libs (e.g. only gcc-4.8 had USE=fortran, but you disabled that w/out rebuilding/uninstalling fortran code). this isn't new behavior, so i don't see the blocking behavior mattering here. otherwise, gcc-config has for a long time now sorted the runtime library list based on version. so once you have gcc-5.3 installed, libs from that are at the head of the search list and will be loaded at runtime regardless of what version you're actually compiling with (4.8 or 4.9 or whatever). so unmerging the older versions won't change commit 870b5b35eac735678dbd26650872cc8aeb38c305 Author: Michał Górny <mgorny@gentoo.org> AuthorDate: Tue Jun 21 18:20:18 2016 Commit: Michał Górny <mgorny@gentoo.org> CommitDate: Tue Jun 21 19:20:46 2016 toolchain-binutils.eclass: [QA] Remove USE=multislot, #584610 The USE=multislot was used only to control build-time blocker on previous versions of binutils. However, there is no technical reason not to have multiple binutils versions installed at build time (or run time). Considering that the flag does not control the installed files or the package in any other way, it is an invalid use of USE flags. commit 6521d68830165d2a140ef661be83d40319de0c39 Author: Michał Górny <mgorny@gentoo.org> AuthorDate: Tue Jun 21 18:05:16 2016 Commit: Michał Górny <mgorny@gentoo.org> CommitDate: Tue Jun 21 19:20:38 2016 toolchain.eclass: [QA] Remove meaningless USE=multislot, #584610 The USE=multislot as defined partially by toolchain.eclass and partially by sys-devel/gcc was used for two purposes: - enabling build-time (only) blockers on old gcc versions -- which do not make any sense because they are build-time only and there is no technical reason for two gcc version ranges not to be installed at the same time, both at build time and at run time, - changing behavior of post-install wrt conditional gcc-config calls. Both cases are invalid use of USE flags, considering that the flag does not affect the installed files in any way. |