Consider the following. a.ebuild: inherit x autotools x.eclass: AUTOTOOLS_AUTO_DEPEND=no inherit autotools Considering that x.eclass uses one of autotools.eclass functions but doesn't need DEPENDs added to all packages using it. This used to work fine before; the second inherit of autotools added necessary DEPENDs as requested by the ebuild. Nowadays, with the double-inherit prevention the dependencies are no longer added and random packages fail to build in the tree.
would be easy to add a check to the autotools.eclass though so ebuild maintainers would know up front they have to include autotools first -- if they don't, the eclass would call `die`. not sure if this would block any workflows though.
(In reply to comment #1) > would be easy to add a check to the autotools.eclass though so ebuild > maintainers would know up front they have to include autotools first -- if > they don't, the eclass would call `die`. not sure if this would block any > workflows though. And it would cause even a larger and more noticeable failure when a number of ebuilds starts to die randomly.
you have to provide an example of how an ebuild would start to "randomly" die. once all existing ebuilds are fixed, then anything new written would get the right behavior from the start. i'm not looking for useless hyperbole but actual examples.
(In reply to comment #3) > you have to provide an example of how an ebuild would start to "randomly" > die. once all existing ebuilds are fixed, then anything new written would > get the right behavior from the start. Are you willing to find all broken ebuilds _including_ those in overlays and fix them?
(In reply to comment #4) > (In reply to comment #3) > > you have to provide an example of how an ebuild would start to "randomly" > > die. once all existing ebuilds are fixed, then anything new written would > > get the right behavior from the start. > > Are you willing to find all broken ebuilds _including_ those in overlays and > fix them? It is up to the overlay authors to keep up with what is happening in the main tree; not the other way around.
(In reply to comment #5) +1 we can go either way: eclass silently supports any inherit order at a performance penalty, or the eclass includes warnings to enforce the order to keep the current performance gains. obviously i prefer the latter as the long term is better at the cost of more short term work. so if there are no examples as to why this won't work, that's the direction we'll take.
(In reply to comment #6) > (In reply to comment #5) > > +1 > > we can go either way: eclass silently supports any inherit order at a > performance penalty, or the eclass includes warnings to enforce the order to > keep the current performance gains. > > obviously i prefer the latter as the long term is better at the cost of more > short term work. so if there are no examples as to why this won't work, > that's the direction we'll take. Or check for the variable changes but who would think of doing the easier thing. You can just use its value instead of that wannabe-asciiart, then it would be sourced twice when the order is incorrect. Of course, that would damage the 'performance gain'.
(In reply to comment #7) sounds to me you have no actual examples but instead can only make lame attacks. so i'll move on with the proposal i made since no one has any fact-based objections.
Created attachment 312339 [details, diff] autotools-utils.eclass: fix AUTOTOOLS_AUTO_DEPEND handling Michał: you'll need this patch for autotools-utils.eclass. or i can just commit it. lemme know either way.
(In reply to comment #9) > Created attachment 312339 [details, diff] [details, diff] > autotools-utils.eclass: fix AUTOTOOLS_AUTO_DEPEND handling > > Michał: you'll need this patch for autotools-utils.eclass. or i can just > commit it. lemme know either way. That doesn't change a thing. Just rename + forced override of user-specified variable.
(In reply to comment #10) read it closer. the variable now stays set instead of changing values past the inherit statement.
Committed.
well, that eclass is only one of the ones we need to fix first before i can enable misbehavior detection
i've fixed xfconf.eclass as it was forcing AUTOTOOLS_AUTO_DEPEND to no even when ebuilds were not using EAUTORECONF but were trying to run autotools themselves: http://sources.gentoo.org/eclass/xfconf.eclass?r1=1.46&r2=1.47 and i've deployed the fatal check in case the value changes: http://sources.gentoo.org/eclass/autotools.eclass?r1=1.168&r2=1.169
