Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 584610 - [QA] sys-devel/gcc[-multislot] blockers and upgrade behavior change
Summary: [QA] sys-devel/gcc[-multislot] blockers and upgrade behavior change
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: [OLD] Unspecified (show other bugs)
Hardware: All Linux
: Normal QA (vote)
Assignee: Gentoo Quality Assurance Team
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: 582504
  Show dependency tree
 
Reported: 2016-05-30 20:43 UTC by Michał Górny
Modified: 2016-06-21 17:21 UTC (History)
9 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 2016-05-30 20:43:41 UTC
Since there are multiple complaints about the new sys-devel/gcc behavior coming both from users and QA team members, I'd like to request QA team vote on the issue.

I'd like to propose the following motion:

1. USE=multislot (as defined now) must be removed from sys-devel/gcc along with the blockers on old versions. The removal of old gcc versions does not need to be forced and can be done using standard package manager mechanisms (e.g. --depclean in Portage).

2. Toolchain team is requested not to switch gcc versions automatically when it involves significant ABI changes, such as the upgrade to gcc5. As long as we lack proper clean upgrade path, the user should be required to explicitly run the upgrade.

3. We suggest adding a pkg_prerm() check that would prevent the PM from removing currently active gcc version, unless the switch to another gcc version is planned as a part of the current batch. We will provide a reference implementation later.

4. Finally, we would like to remind toolchain team that is is inappropriate to perform multiple breaking changes on stable ebuilds without revbumping.


The rationale:

A. Blockers should be used to block two or more packages from being installed simultaneously when there are technical reasons preventing their coexistence. This is not the case here, and there is no technical reason for new gcc versions to block old ones.

B. USE flags should be used to control features and specifics of installed packages. In this case, the USE flag does not cause any change to the package's behavior and only indirectly affects existence of other installed packages. This is not a legitimate use of the flag, and not a justified case.

C. Automatic major gcc version switch can involve libstdc++ ABI incompatibility. For example, after switching to gcc5 it is necessary to *manually* rebuild many C++ libraries and their reverse dependencies. The premature switch results in new C++ package builds either failing due to ABI mismatches, or breaking reverse dependencies.

D. The 'moving blocker' idea would extend the above issue to the state that when gcc5 goes stable, people using stable would not only automatically switch to gcc5 but remove gcc4 immediately, therefore losing the ability to easily revert the breaking change.


Please vote.
Comment 1 Ulrich Müller gentoo-dev 2016-05-30 21:43:13 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.
Comment 2 Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 2016-05-31 07:12:25 UTC
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.
Comment 3 Patrick Lauer gentoo-dev 2016-06-01 05:16:05 UTC
Yes to all 4 points
Comment 4 Mikle Kolyada (RETIRED) archtester Gentoo Infrastructure gentoo-dev Security 2016-06-11 21:13:35 UTC
1/2: yes
3/4 abstain
Comment 5 SpanKY gentoo-dev 2016-06-13 18:28:53 UTC
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.
Comment 6 Anthony Basile gentoo-dev 2016-06-13 21:11:20 UTC
(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)
Comment 7 SpanKY gentoo-dev 2016-06-13 21:46:47 UTC
(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.
Comment 8 SpanKY gentoo-dev 2016-06-14 12:30:58 UTC
(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.
Comment 9 Anthony Basile gentoo-dev 2016-06-14 12:45:37 UTC
(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?
Comment 10 Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 2016-06-14 12:49:25 UTC
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.
Comment 11 Anthony Basile gentoo-dev 2016-06-14 19:36:43 UTC
> 
> [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/ ?
Comment 12 SpanKY gentoo-dev 2016-06-15 05:22:55 UTC
(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
Comment 13 Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 2016-06-21 17:21:28 UTC
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.