Please add this ebuild to the tree and a version check to subsequente versions. I for one like to use Gentoo but would like upgrades to be as painful as possible, simple checks like this allow it. Unfortunately not everyone has time to update their systems every week. Reproducible: Always Steps to Reproduce: 1.Have autoconf-2.63 installed 2.Try to install pango-1.28.3 3. Actual Results: Breakage. Expected Results: autoconf-2.65-r1 should be pulled and pango should install without further intervention.
Created attachment 274269 [details, diff] autoconf patched ebuild Patch with autoconf version check.
confirmed. Short excerpt to make this actually useful for the search: ./configure: line 21294: syntax error near unexpected token `}' ./configure: line 21294: `$as_echo "$as_me: error: specified module $module not recognized" >&2;}' ./configure: line 16: AA: command not found ./configure: line 17: ABI: command not found ./configure: line 18: ACCEPT_LICENSE: command not found ./configure: line 19: ACLOCAL: command not found ./configure: line 20: ALSA_CARDS: command not found Tiago, next time, follow the bug reporting guidelines and attach build.log and the other information we ask for.
Comment on attachment 274269 [details, diff] autoconf patched ebuild autoconf has no place in RDEPEND.
(In reply to comment #2) > confirmed. > > Short excerpt to make this actually useful for the search: > ./configure: line 21294: syntax error near unexpected token `}' > ./configure: line 21294: `$as_echo "$as_me: error: specified module $module not > recognized" >&2;}' > ./configure: line 16: AA: command not found > ./configure: line 17: ABI: command not found > ./configure: line 18: ACCEPT_LICENSE: command not found > ./configure: line 19: ACLOCAL: command not found > ./configure: line 20: ALSA_CARDS: command not found > > Tiago, next time, follow the bug reporting guidelines and attach build.log and > the other information we ask for. Sorry, forgot that since I already I had solution I thought would work. I didn't notice DEPEND vs RDEPEND as I've never written an ebuild, sorry. It's clear to me now why it is wrong. I'll send a fixed ebuild shortly.
Created attachment 274279 [details, diff] Fixed from RDEPEND to DEPEND Updated patch with autoconf dependency in DEPEND
Well, on the other hand, 2.65-r1 has been in stable for over 8 months - 'emerge -upvD --with-bdeps y world' should have picked that up long ago.
(In reply to comment #6) > Well, on the other hand, 2.65-r1 has been in stable for over 8 months > - 'emerge -upvD --with-bdeps y world' should have picked that up long ago. Right, I know that. I'm not here complaining that old setups have not been tested, I'm just asking that since they pop up once in a while, they should be taken care of in ebuilds since this is clearly a bug. The system doesn't think it needs a more recent version of one package and then proceeds to crash and burn. I've been a Gentoo user for more than 5 years and never once used "emerge -upvD --with-bdeps", nor is it a good policy to do an emerge world every week, only when one has the time to constantly jump through the dozens of problems that pop up along the way. I have not had a relatively painless "emerge world" for years. I'm just asking that when these problems pop up they are addressed(if there isn't an automated way to get dependencies from configure scripts), instead of being closed like this particular ebuild has been before I stumbled into the error. Is this possible or is it going against any particular Gentoo policy? Best regards, Tiago
I'd say there's a slight difference between "update every week" and "has been stabled over 8 months ago". The usual effect of letting problems pile up is that you'd receive "reinstall would be quicker" response on the forum. A remark about policing common sense would fit here.
I've had problems from an old install that was still using GCC-3.4.6 after two years or so after GCC-4.1 had gone stable, which I know was something I should've update long before. In this situation, I don't find it something out of the ordinary: most distributions, operating systems, get at least a three year support cycle(18 months at the least), so I think this is something worth looking into. Updating stuff like browsers, productivity programs, etc, is obviously important but autoconf and the like? If nothing in Portage is pushing a new version to update, having to do an emerge world with that frequency is not something most people would like to do on an a frequent basis. Once a year? Yeah, sure, why not? But every month or so? Keep this in mind, please. All I'm asking is adding dependencies like this one when they pop around in a bug report, instead of closing as wontfix. Best regards
Well, actually for Gentoo 1 year is the *upper* limit. Also, once a package hits stable, unless it's slotted, its previous versions are rarely ever tested again - it's just waiting till the maintainer decides to remove it (there are exceptions to this, i.e. wine, but that's the usual way).
+ 05 Jun 2011; Pacho Ramos <pacho@gentoo.org> -pango-1.28.1.ebuild, + -pango-1.28.3.ebuild, pango-1.28.4.ebuild: + Block old sys-devel/autoconf versions to prevent upgrade problems like bug + #368333. Remove old. +
