That may be, but these same problems will happen if/when it moves to stable. I agree with Ben, these are issues that can/should be worked around in the package, not in the user.
Dear Ben and Ben,
while you are right in principle and these problems should, of course, be fixed in the package, I do not agree with the assessment of what is needed in the short run.
And seriously folks, i am still sick of this "user must {force
depends, remove old first, manually do <foo>} to use the new version of my package" bullshit which has been happening more and more recently.
This has not been happening more and more recently. This has been happening regularly when big updates where put into unstable. It is a first aid to users who otherwise would be blocked and could not continue to build the new unstable packages and detect more bugs.
There are solutions for everything. The last, last, last resort is
You are forgetting the time factor. There are short-term solutions and long-term solutions. Plus, finding the short-term solution gave a hint what the cause of the error is (the maintainer obviously hadn't seen the error himself or he would have fixed it).
You only reported the error to a forum where the same error had been reported before, without looking at its cause or giving any hint at how it could be solved.
I took at least the time to find out where the error came from and I gave a temporary workaround. And I announced this workaround on fink-gnome-core so that the maintainer was aware of it, and on fink-devel so that others could help think about a real solution.
having the user do something. If a temp upgrade-package is required, then that is preferred over having the user do something. If modifying %p is required, then that is preferred to having the user do something. Often there are much easier build time fixes. (as in this case) There is always a way. If a user must manually do something to update a package, please file a bug on the bug tracker.
STILL cause people to leave fink.
These situations are NOT acceptible to fink users. These situations
I disagree again. What is more likely to cause people to leave fink (people here mean users who were lured by the infomation-less ramblings on the fink home page to try out the new gnome-2.4, who knew that this was unstable and were prepared to meet some difficulties, but who often had not much prior experience with Fink):
An answer like I gave: Do "fink remove freetype freetype-hinting librsvg2", your build will then work,
Or an answer that you seem to prefer: "The bug you are reporting has been taken into account, thank you, the maintainer will look after it as soon as he has the time, come back in about two weeks"
Do you want people go away after having reported one bug, or do you want to help them with a quick hack so they can continue building the new stuff and find more bugs and/or try out the new programs?
For me, the choice is clear.
-- Martin
------------------------------------------------------- This SF.net email is sponsored by: Perforce Software. Perforce is the Fast Software Configuration Management System offering advanced branching capabilities and atomic changes on 50+ platforms. Free Eval! http://www.perforce.com/perforce/loadprog.html _______________________________________________ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
