| Summary: | [Future EAPI] Ability to mask USE flags only on stable systems | ||
|---|---|---|---|
| Product: | Gentoo Hosted Projects | Reporter: | Arfrever Frehtes Taifersar Arahesis (RETIRED) <arfrever> |
| Component: | PMS/EAPI | Assignee: | PMS/EAPI <pms> |
| Status: | RESOLVED WONTFIX | ||
| Severity: | normal | CC: | esigra, python, spatz |
| Priority: | High | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | All | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Bug Depends on: | |||
| Bug Blocks: | 174380 | ||
|
Description
Arfrever Frehtes Taifersar Arahesis (RETIRED)
2010-06-05 15:56:29 UTC
So you want packages to magically change behaviour when they're marked stable? (In reply to comment #1) No. Behavior should change depending on keywords accepted by user. Many packages might have the following dependencies: python_abis_2.6? ( dev-lang/python:2.6 ) python_abis_2.7? ( dev-lang/python:2.7 ) python_abis_3.1? ( dev-lang/python:3.1 ) python_abis_3.2? ( dev-lang/python:3.2 ) python_abis_3.3? ( dev-lang/python:3.3 ) USE flags like python_abis_2.7, python_abis_3.2 and python_abis_3.3 should be globally masked in use.mask *only until* unmasking of relevant slots of dev-lang/python in the tree. After unmasking them, users who accept unstable keywords should be able to actually test hundreds of reverse dependencies with the new slot of dev-lang/python. Stabilization of the new slot of dev-lang/python will be possible after several months of testing of reverse dependencies. For users who don't accept unstable keywords, the new slot of dev-lang/python would be temporarily masked by unstable keywords and the relevant USE flag also should be masked (by use.mask.stable proposed in this bug). My idea is to create a global "unstable" profile and to create versions of the "stable" profiles from profiles.desc that inherit from the global "unstable" profiles and are marked as "dev" profiles. Wouldn't that work? Please let me know if you see any problems. Maybe users who use package.keywords would have to do some additional tweaks if they want "unstable" masked USE settings, but that seems perfectly acceptable. This proposal is whacked from a QA standpoint- the purpose of stable/unstable is to get changes ready in unstable, make sure they work, then push them into stable. The purpose of stable is to *be* stable. Both proposal's here result in what's being tested in unstable not matching what will be pushed into stable... it's basically a castration of stable. -1 from me, both profile wise and PMS wise. I feel dirty for saying this, but I'm with Brian on this one. It's asking for way too much magic, and it's a huge change to what stable and unstable mean conceptually. Mmmmaybe what could be done is some way of marking IUSE values for the package manager to say "force this flag off if it introduces dependency constraints that can't possibly be satisfied". So (using exheres-0-like syntax): IUSE="python_abis_3.3 [[ auto-mask = [ if-unsatisfiable ] ]]" Then the package mangler would have a look at all dependencies introduced by a python_abis_3.3? ( ) block, and if any of them (or all for things inside '|| ( )') have no visible versions, then it treats the flag as masked. But again, it's a lot of nasty trickery, and horrible from a QA perspective. (In reply to comment #5) > Mmmmaybe what could be done is some way of marking IUSE values for > the package manager to say "force this flag off if it introduces dependency > constraints that can't possibly be satisfied". So (using exheres-0-like > syntax): > > IUSE="python_abis_3.3 [[ auto-mask = [ if-unsatisfiable ] ]]" > > Then the package mangler would have a look at all dependencies introduced > by a python_abis_3.3? ( ) block, and if any of them (or all for things > inside '|| ( )') have no visible versions, then it treats the flag as masked. I can accept any solution, which ensures that we don't have to maintain 2 sets of ebuilds of hundreds of packages. (In reply to comment #6) > I can accept any solution, which ensures that we don't have to maintain 2 sets > of ebuilds of hundreds of packages. Going by your opening comment, what you're actually saying here is "I can accept any solution, which ensures that we don't have to maintain stable and unstable dependencies." Basically, you don't want to have to manage the stable/QA work. I grok that, it's a pain in the ass- that seperation between stable/unstable exists for a reason however, to ensure there is a QA period for introducing changes into the tree. If you want to castrate the QA steps of unstable to stable via having what is intended to be stabled not match what was test, take it to the ml rather than this venue- you're basically trying to sidestep policy and the proper steps for stabling a pkg. This isn't a technical limitation, nor is it a pkg format limitation- your beef is with stable/unstable seperation (policy/QA), thus go elsewhere. As for Ciaran's comment, optional dependencies ('suggested') is orthogonal to this- suggested dep's must not be used just to avoid doing proper stabling work. QA ought to crack the nuts of anyone who tries to do that also. Suggested deps ought to be a seperate ticket for tracking also. Closing this... 1) not the right venue, 2) it's not PMS's place to be making policy decisions like this, 3) if 2 out of the 3 package manager developers go "blech" immediately the proposal has some flaws, 4) even if this were the right venue, you would need external discussion for such a change (meaning devs/folks agreeing with it) which doesn't exactly seem to exist. Open a seperate suggested deps ticket if you'd like, but I'm killing this one off; reopen if it manages to address at least a couple of the issues mentioned. |