On Aug 11, 2010, at 10:20 PM, Thomas Goirand wrote: > As you see, there's no need to use cd or /bin/echo or even /bin/sh. It's > a lot cleaner this way. >
Cool! Very nice. > Now, I'd like to do more or less the same with the mysql tests. But in > fact, I'm not sure yet we really want to add these MySQL and Postgress > tests: this has a lot of chances to fail in many ways: for example if > someone has configured the mysql/postgress server in a way that your > test wouldn't like, or if something else is binding on the same port and > on 127.0.0.2. By the way, why did you think we need to have MySQL bind > on an IP? Can't we just do a --skip-networking or something, so that the > tests are just using the socket files? If that was the case, then I > think it would be a lot more safe to leave the MySQL test. I didn't have > time to look into the postgresql tests, but I believe that might be the > same issue here. My primary focus is on having the tests fail on a clean build machine if the driver is broken, or mysql/postgresql change their behavior in a an unexpected or significant manner. Failing early is a good thing! Rather than waiting for users to report odd behavior, these tests should give us a chance of catching the easy stuff before it gets that far. So, I'd rather see the build fail occasionally than burden users with easy bugs. For somebody who is just building the package for themselves on a system that is already serving mysql/postgres in a way that conflicts with the test, well, I'm ok with just skipping the tests. They should not fail the build unless they actually find the test mysqld or postgres and try to run the tests. The most likely case of this would be somebody who binds the DB service to 0.0.0.0. So be it for now. As long as these run on the buildd's, I'm happy with it. It might be good to trigger some kind of build warning on skipped tests, but I'm not really sure how to do that. The reason for binding to an ip rather than sockets is the limitations of test_dbi. As Markus says, it appears 0.9 has a new test suite, so maybe it will support passing in arbitrary driver options (if not, it really should). Otherwise, there's currently no obvious way to pass in mysql_unix_socket or pgsql_port (which sets the path to the socket). -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
