Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 174184 - USE=multislot violates metadata invariance requirements
Summary: USE=multislot violates metadata invariance requirements
Status: RESOLVED LATER
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Eclasses (show other bugs)
Hardware: All Linux
: High normal (vote)
Assignee: Gentoo Toolchain Maintainers
URL:
Whiteboard:
Keywords:
: 187046 (view as bug list)
Depends on:
Blocks:
 
Reported: 2007-04-11 17:56 UTC by Ciaran McCreesh
Modified: 2008-10-18 15:12 UTC (History)
11 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 Ciaran McCreesh 2007-04-11 17:56:52 UTC
The toolchain.eclass >> SLOT+IUSE logic << section violates the metadata invariance requirements by introducing use-variance on SLOT. SLOT, like other metadata variables, is required to be independent of user configuration. The current behaviour leads to broken dependency resolution.
Comment 1 SpanKY gentoo-dev 2007-04-11 18:18:23 UTC
you already know the answer, stop wasting people's time
Comment 2 Ciaran McCreesh 2007-04-11 18:24:37 UTC
If you really are going to fix this LATER, when will that be? What are your plans for ensuring that this really will be fixed, and not just ignored?

This one's the same category of QA violation as bug 24439. Brushing it under the carpet isn't exactly a decent solution...
Comment 3 SpanKY gentoo-dev 2007-04-11 18:30:55 UTC
your opinion on this matter is not wanted so stop giving it

if your opinion is ever wanted, i'll let you know
Comment 4 Ciaran McCreesh 2007-04-11 18:54:25 UTC
Whether or not it is broken is not a matter of opinion, and does not vary based upon who says it.
Comment 5 Danny van Dyk (RETIRED) gentoo-dev 2007-04-11 19:31:10 UTC
As discussed with Mike on IRC: He and me consider having an xDEPEND-like syntax for SLOT would as a proper solution to this bug.

  SLOT="multislot? ( ${PF} ) !multislot? ( $(strip-versions ${PV}} )"

Portage-team: What do you think about this? Are there any problems with implementation?
Comment 6 Kevin F. Quinn (RETIRED) gentoo-dev 2007-04-11 19:48:58 UTC
If this is the only occurrence of USE-variant SLOTs, could the gcc SLOTS simply be always named "${CTARGET}-${GCC_CONFIG_VER}"?  (or at least, something that would be unique across all GCC targets and versions, regardless of multislot, cross-compile etc).
Comment 7 SpanKY gentoo-dev 2007-04-11 19:51:48 UTC
no ... CTARGET is not part of the cache and forcing the SLOT to one value goes against the point of USE=multislot
Comment 8 Danny van Dyk (RETIRED) gentoo-dev 2007-04-11 20:13:45 UTC
Short summary:
* (some) Arch teams and toolchain ninjas want support to install several minor
  gcc versions in parallel. Dito for major binutils versions.
* The userbase has no need to use this.
* multislot useflag is breaking the metadata cache, so QA team wants this
  (rightfully) to be solved as soon as possible.
* Mike doesn't like use.mask'ing the flag, his chain of arguments is iirc:
  - People who need it set the flag
  - People who need it know what they do
  - Only people who know what they do break their metadata cache.

I for one could live with blocking this bug by an EAPI=1 tracker that includes
xDEPEND-syntax.

Yes, it is a QA violation.
Yes, it needs to die ASAP.
No, we don't have a proper solution for this right _now_.
No, this is not to be used as a precedence for other people who want to screw
with metadata invariance.
Comment 9 Ciaran McCreesh 2007-04-11 20:18:01 UTC
Except that users end up setting it anyway, whether or not they know what it does, and they get harmed as a result. use.masking it avoids this by making users go out of their way to get it if they really really need it. Other use flags with similarly weird behaviour are generally marked with lots of !!!s or are profile-controlled.
Comment 10 SpanKY gentoo-dev 2007-04-11 20:34:43 UTC
well that sucks to be those users ... refer to comment #3 and comment #8
Comment 11 Ciaran McCreesh 2007-04-11 20:37:45 UTC
In other cases where users are given the choice of doing something that will lead to highly weird behaviour, they are warned in advance. The same should happen here.

And stop trying to avoid the issue. You're subject to the same rules regarding QA as everyone else. See comment #4.
Comment 12 SpanKY gentoo-dev 2007-04-11 20:42:23 UTC
this was already fully discussed on irc (which kugelfang posted a summary of)

you apparently werent happy with that answer so you decided to waste our time with a bug report where you got the same exact answer (imagine that)

your input is still not wanted so stop giving it as it wont change anything here
Comment 13 Ciaran McCreesh 2007-04-11 20:46:43 UTC
You're attempting to brush the issue under the carpet by refusing to discuss it. I escalated it to a bug so that interested parties can comment upon it and be aware of the breakage.
Comment 14 SpanKY gentoo-dev 2007-04-11 20:52:34 UTC
perhaps you should actually try reading comment #3 and comment #8
Comment 15 Ciaran McCreesh 2007-04-11 20:56:58 UTC
Perhaps you should try reading comment #4 and comment #9 and comment #11.
Comment 16 SpanKY gentoo-dev 2007-04-11 21:00:55 UTC
where exactly did i give the impression that we wanted to hear what you have to say ?  let me know so i can rectify that

the "concerned parties" (which, incidentally, do not include you) have already come to a solution (comment #8)

do us a favor and go away now
Comment 17 Ciaran McCreesh 2007-04-11 21:09:04 UTC
Comment #8 only describes a possible long term solution. You haven't addressed the short term, other than to say that you personally don't want to fix it. At least two short term solutions have been offered that are better than doing nothing, which I shall repeat for your convenience:

* use.masking the flag
* Adding a !!!warning!!! to the flag's description.

Either of these, whilst not fixing the QA violation, will provide a substantial improvement over the current situation.

And, as you know, QA is everyone's concern.
Comment 18 SpanKY gentoo-dev 2007-04-11 21:13:31 UTC
i see no need for a short term solution

as to whether you feel there's a need -> comment #3

i'm done wasting my time on you here
Comment 19 Ferris McCormick (RETIRED) gentoo-dev 2007-04-11 21:41:27 UTC
Please cut this off.  It was useful up to, say, Comment 11.  I note in passing that Comments 3, 12, and 16 are out of line.  No matter how a developer feels personally, developers owe users some amount of respect, and in my opinion "please go away, your opinion is not wanted" falls below whatever the minimal standard is.

If ciaranm has a legitimate bug here (and QA (spb) tells me he does), and if he is proposing possible solutions, then they need proper evaluation, not "we don't want to hear from you".

ciaranm:  At this point, further comment will change this bug from a (mostly) reasonable discussion into a flamefest or a sequence of name callings.  Please do not do that.  I suggest that you and QA work with Kugelfang along the lines of Comments 8 and 17.  Nothing will be achieved by a fight between you and SpanKY on this bug because the two of you are not communicating with each other.

Regards,
Ferris
Comment 20 Steve L 2007-04-19 11:22:37 UTC
- Only people who know what they do break their metadata cache.
If it's only their own cache, that's their lookout. Why make it awkward for people to help out?

FWIW I agree that SpanKY's comments are unprofessional. I understand that ciaranM carries on in the same way on IRC, but this isn't IRC and as the saying goes: "Don't fight an idiot, he'll only drag you down to his own level and beat you with his experience."

* Adding a !!!warning!!! to the flag's description.
Seems like a reasonable compromise to this old fart ;)
Comment 21 Wernfried Haas (RETIRED) gentoo-dev 2007-04-19 16:41:40 UTC
[Proctors notice]

(In reply to comment #20)
> FWIW I agree that SpanKY's comments are unprofessional. I understand that
> ciaranM carries on in the same way on IRC, but this isn't IRC and as the saying
> goes: "Don't fight an idiot, he'll only drag you down to his own level and beat
> you with his experience."

While this bug has seen some unprofessional behaviour already, which was put out nicely by Ferris (thanks), there is no reason to revive it again. Anyone tempted to jump in on it again with non productive or non related comments:
Please don't.

Thanks
[End of notice]
Comment 22 Steve L 2007-04-20 07:02:23 UTC
Err apologies then.
> Except that users end up setting it anyway, whether or not they know what it
> does, and they get harmed as a result. use.masking it avoids this by making
> users go out of their way to get it if they really really need it. Other use
> flags with similarly weird behaviour are generally marked with lots of !!!s
> or are profile-controlled.
Hence:
* Adding a !!!warning!!! to the flag's description.
Seems like a reasonable compromise.
There's no reason it can't be done now, is there? In which case, adding it would at least give more warning to users that it was a dev flag, as Ciaran requested.
Comment 23 Stefan Huszics 2007-04-22 01:02:36 UTC
* multislot:Allow for SLOTs to include minor version (3.3.4 instead of just 3.3)


I am a USER of Gentoo and only by chance was I warned NOT to enable Multislot a while ago. Everything the description of the useflag tells me is that it might cause LESS breakage (needed to be fixed by revdep-rebuild) by keeping more versions around on the system. Nowhere does it even imply that things will get FUBARed if you use it and that it's ONLY to be used by people that know what they are doing.


Thus, the "logic" of not fixing this just doesnt hold water IMO.


Further I must add that some people really have stop judging issues&bugs depending WHO is reporting it... You are making both an ass of youself as well as hurt the entire gentoo user community in the process by ignoring REAL issues just because you dont like the person that brought it up.
Comment 24 Steve L 2007-06-12 02:44:30 UTC
(In reply to comment #23)
> * multislot:Allow for SLOTs to include minor version (3.3.4 instead of just 
3.3)
> 
> I am a USER of Gentoo and only by chance was I warned NOT to enable Multislot 
a while ago. Everything the description of the useflag tells me is that it 
might cause LESS breakage (needed to be fixed by revdep-rebuild) by keeping 
more versions around on the system. Nowhere does it even imply that things will 
get FUBARed if you use it and that it's ONLY to be used by people that know 
what they are doing.
>
I agree. Personally I feel Ciaran's approach is better, but the short term fix 
can go in immediately and would cause less bug-reports and less ill-feeling as 
users get mocked for using a dev-only flag. The principle of making it easy to 
tinker is hard to resist though, especially for a source distro. Whether anyone 
with commit access will bother to take the 2 minutes required to amend the 
descr/flag is another matter.
Comment 25 Piotr Jaroszyński (RETIRED) gentoo-dev 2007-07-01 16:56:57 UTC
(QA) As the short term solution I have added a warning to the multislot useflag so the users won't enable it blindly.
Comment 26 Jakub Moc (RETIRED) gentoo-dev 2007-07-29 18:52:33 UTC
*** Bug 187046 has been marked as a duplicate of this bug. ***