Since mgorny wants this in a new bug, continuing discussion from bug 386041 here. (In reply to Michał Górny from comment #10 on bug 386041) > > b) Why have you gone back to 'python' instead of 'python-bindings'? Do you > > understand why we aren't using the 'python' flag to begin with? This > > *really* shouldn't be on by default. > > I don't see any of the profiles enabling python by default. If you do mind > using USE=python for what it is used for, describe the problem to the ml, > get a consensus, prepare the plan and we will work on doing it. When we had that flag under USE=python, we kept getting people complaining that they were being OOMed during the build. Boost.Python uses obscene amounts of RAM during the build, particularly with debugging turned on, and there more files in that directory than most people have jobs in MAKEOPTS. Since even people who use Python regularly generally don't have a use for the Python bindings, and since building them is very expensive, the Python bindings shouldn't be on under a USE flag that people are likely to have enabled for other reasons. The question here, though, is why you changed something that was obviously done deliberately, without understanding why it was done that way or what the consequences of overriding that deliberate decision would be. > > d) Why are you hard-enabling prebuilt-documentation? This should usually be > > disabled. > > Why should people rebuild documentation at every build? To get a different > date in the footer? To get documentation for the program they've actually built that describes options they have enabled, rather than a generic version we supply for people who are cross-compiling who can't run built programs. Again, why are you changing things when you don't understand what they do?
(In reply to Ciaran McCreesh from comment #0) > When we had that flag under USE=python, we kept getting people complaining > that they were being OOMed during the build. Boost.Python uses obscene > amounts of RAM during the build, particularly with debugging turned on, and > there more files in that directory than most people have jobs in MAKEOPTS. What you are describing is a problem with the package and not with the ebuild. I doubt that we can do much about it. > Since even people who use Python regularly generally don't have a use for > the Python bindings, and since building them is very expensive, the Python > bindings shouldn't be on under a USE flag that people are likely to have > enabled for other reasons. $ quse -D python global:python: Add optional support/bindings for the Python language What is the 'other reason' to enable this flag globally? > The question here, though, is why you changed something that was obviously > done deliberately, without understanding why it was done that way or what > the consequences of overriding that deliberate decision would be. This doesn't belong in a bug report and please restrain from future remarks like this in order to ensure a friendly environment around here. > > > d) Why are you hard-enabling prebuilt-documentation? This should usually be > > > disabled. > > > > Why should people rebuild documentation at every build? To get a different > > date in the footer? > > To get documentation for the program they've actually built that describes > options they have enabled, rather than a generic version we supply for > people who are cross-compiling who can't run built programs. Again, why are > you changing things when you don't understand what they do? Could you be more specific here? Preferably describe with examples on what changes and why. You have to have a strong argument to force a few extra minutes of build time to actually get less content than in the generic supplied docs.
(In reply to Michał Górny from comment #1) > (In reply to Ciaran McCreesh from comment #0) > > When we had that flag under USE=python, we kept getting people complaining > > that they were being OOMed during the build. Boost.Python uses obscene > > amounts of RAM during the build, particularly with debugging turned on, and > > there more files in that directory than most people have jobs in MAKEOPTS. > > What you are describing is a problem with the package and not with the > ebuild. I doubt that we can do much about it. No, it's a problem with the ebuild passing bad values to the build system. > > Since even people who use Python regularly generally don't have a use for > > the Python bindings, and since building them is very expensive, the Python > > bindings shouldn't be on under a USE flag that people are likely to have > > enabled for other reasons. > > $ quse -D python > global:python: Add optional support/bindings for the Python language > > What is the 'other reason' to enable this flag globally? Wanting Python bindings enabled for Paludis is entirely unrelated to wanting them enabled for another package. > > The question here, though, is why you changed something that was obviously > > done deliberately, without understanding why it was done that way or what > > the consequences of overriding that deliberate decision would be. > > This doesn't belong in a bug report and please restrain from future remarks > like this in order to ensure a friendly environment around here. No, this is a serious issue: you've added yourself as a maintainer to a package whose ebuilds you don't understand, and made a load of changes to the ebuilds without understanding why the things you changed were that way to begin with. The correct fix here is a) to go back to the old ebuilds, and b) for you to agree not to change them until you've checked your changes with someone who does understand them. > > > > d) Why are you hard-enabling prebuilt-documentation? This should usually be > > > > disabled. > > > > > > Why should people rebuild documentation at every build? To get a different > > > date in the footer? > > > > To get documentation for the program they've actually built that describes > > options they have enabled, rather than a generic version we supply for > > people who are cross-compiling who can't run built programs. Again, why are > > you changing things when you don't understand what they do? > > Could you be more specific here? Preferably describe with examples on what > changes and why. You have to have a strong argument to force a few extra > minutes of build time to actually get less content than in the generic > supplied docs. The pre-built docs are simply a convenience for people who cross-compile, since autotools+libtool doesn't do generated files very well when cross-compiling. The "generic supplied docs" are not "generic", they're "enough to cross-compile if you can't build them properly". Again, you removed a feature without understanding what that feature is. The correct fix here is also a) to go back to the old ebuilds, and b) for you to agree not to change them until you've checked your changes with someone who does understand them.
Reopen when you are willing to give real insight rather than 'you are always wrong, I am always right'.
The insight is already there, you're just deliberately ignoring it. For example: > The pre-built docs are simply a convenience for people who cross-compile, since > autotools+libtool doesn't do generated files very well when cross-compiling. > The "generic supplied docs" are not "generic", they're "enough to cross-compile > if you can't build them properly". QA: please revert mgorny's changes and find a new maintainer for Paludis on Gentoo.
(In reply to Ciaran McCreesh from comment #4) > The insight is already there, you're just deliberately ignoring it. For > example: > > > The pre-built docs are simply a convenience for people who cross-compile, since > > autotools+libtool doesn't do generated files very well when cross-compiling. > > The "generic supplied docs" are not "generic", they're "enough to cross-compile > > if you can't build them properly". I was asking for an example since I wasn't been able to find a single difference between prebuilt docs and generated docs (except for the date of generation).
(In reply to Ciaran McCreesh from comment #4) > The insight is already there, you're just deliberately ignoring it. For > example: > > > The pre-built docs are simply a convenience for people who cross-compile, since > > autotools+libtool doesn't do generated files very well when cross-compiling. > > The "generic supplied docs" are not "generic", they're "enough to cross-compile > > if you can't build them properly". > > QA: please revert mgorny's changes and find a new maintainer for Paludis on > Gentoo. As the primary maintainer of Paludis (see metadata.xml), I am OK with mgorny's changes. As upstream, unless you can point out a significant engineering issue with his changes and not just "They do not agree with my personal decisions", this is not a QA problem and mgorny's changes will not be reverted.
Since you're not prepared to handle this properly, I'll just remove the features entirely for Gentoo. No point making the majority of users suffer for something that's just there for rare cases.
