Summary: | USE="-nls" should be handled in econf() | ||
---|---|---|---|
Product: | Portage Development | Reporter: | Markus Nigbur (RETIRED) <pYrania> |
Component: | Unclassified | Assignee: | Portage team <dev-portage> |
Status: | RESOLVED WONTFIX | ||
Severity: | normal | CC: | mr_bones_, seemant |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: | Proposed patch |
Description
Markus Nigbur (RETIRED)
![]() Created attachment 16762 [details, diff]
Proposed patch
some older configure scripts dont like it when you pass options it doesnt support ... thus if you go passing --enable-nls or --disable-nls to a script that doesnt have nls comments it'll die lemme double check on this ... and leave it open in case i'm wrong ... Even if you're right Spanky, I think it'd be better to fix the older ebuilds to handle -nls themselves so that newer ones didn't have to. i know of people who manually added --disable-nls to ebuild.sh since month, they didn't run into problems with any ebuild. i must admit, there _might_ be some packages where your statement is true, if so, please let me know of those. i'm pretty sure i'm able to add a workaround for configure scripts that fail when passing invalid options to it. all i have seen so far check if specific options are passed to them, 'invalid' options will just be ignored. Seemant: Your opinion? RE: what Spanky said in his first comment -- I know of one (there may be more) that is very choosy about wrong options sent to configure. I don't recall which one it is, exactly, but it's somewhere in sys- (I wanna say sys-apps, but I dunno for sure). Now, I do think that nls is an often enough occurrence that it would take a big headache. One way that this might be done gracefully, is just check if the IUSE has "nls" in it? Not sure on that though. I do, however, like the idea of auto-disabling-nls If someone can come up with a difinitive solution to this or wants to take it for exploration, feel free to reopen it. I don't see it as feasable unless someone wants to find and fix all the general/stage1-3+kde/gnome packages in a complete system that break. Can't just deploy this change. Reopening for consideration. Looks like we survived without this for the last three years, and I'm not in favor of adding support for specific USE flags into portage unless absolutely necessary. |