On 27/01/2010 02:36, Matthias Andree wrote:
This isn't acceptable as a generic statement.
Nor is CCing messages to maintainers: http://cygwin.com/acronyms/#PPIOSPE
If you're unwilling to fix the cygport parts of the bug, that's fine, but claiming that fixing it were generally not worthwhile amounts to blessing insecure programming practices.
Remember that cygport serves a single purpose: to build packages, and "fixing" cygport will not guarantee that a package will build in a path containing spaces. For instance, both (autoconf-)configure and libtool (by far the most common build system out there) are shell scripts, and have certainly not worked in these situations in the past. (I can't speak for the current situation wrt these tools.) So there is little benefit in pretending to fix cygport when the result will be exactly the same.
Maybe I should just include a sanity check to force cygport not to run in such paths instead.
Of course fixing cygport won't assure its user that the package itself is safe in paths with blanks, but at least then you can say that you've done your part and the fix is SOEP (someone else's problem).
Shifting the blame on to others won't help anybody one bit. The package STILL will not build, so what has anybody gained?
That other parts might fail is NOT AN excuse to not do your own job in a way that breaks other people's expectations.
I've been around long enough to know that many (most?) people's expectations about Cygwin are generally incorrect. As for those who generally use cygport, namely package maintainers, they obviously DON'T USE SPACES because I can't remember such a complaint before.
I'd seriously ask you to reconsider.
And if this were bugzilla I would be deciding between closing this NOTABUG or WONTFIX. :-)
Yaakov -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
