Hi, Maybe this is pedantic, but it doesn't seem like there's any guarantee, not even with a careful choice of restrictions such as 'isolation-container', that a loopback interface exists when a test is run, or that the name 'localhost' resolves to the testbed. Indeed Debian Policy doesn't prescribe that these work or that opening an Internet Protocol socket be possible. It merely says at https://www.debian.org/doc/debian-policy/ch-source.html#xpointer(//section%5B@id=%22main-building-script-debian-rules%22%5D/p%5B9%5D) that if a socket is opened in the package build process, and if it succeeds, then its subsequent use is permissible. In practice almost all Debian systems should support this, but minimal environments like those used for autopkgtest runs are probably the most likely counterexample if there ever is to be one. Debian Policy's provisions for package builds (which need not apply here) appears to have been very thoughtfully crafted for this problem. Is this something I should write off as "just plain common sense" that doesn't need to be prescribed, or is there a way this ought to be handled? Realistically I think isolation-container and isolation-machine should promise that an Internet Protocol-compatible loopback interface always exists such that listening and connecting to ports on the localhost including the loopback address works. This mainly matters so I can write a test with a server and have a client attempt a connection to it. UNIX domain sockets would be more nice for this purpose but I actually know at least one package maintainer that objects to that, on the basis that real-world usage of daemons like web and mail servers has them listen on the network, and a meaningful test of the system service should try this scenario. That argument is persuasive. Also some programs can't be made to attempt to connect to a UNIX domain socket easily if they demand a hostname and port combo. I think I answered my own question that pragmatism means I should just make this assumption about isolation-container, but since I like to write autopkgtests for packages I use (as opposed to regularly maintain) and submit them to the maintainers, I'm trying to do my due diligence
Attachment:
signature.asc
Description: This is a digitally signed message part