Ben Finney dixit: >That doesn't quite match your request, but I would still like your >opinion on whether you think this correctly addresses the reported >problem.
It doesn’t… I think it could be quite a PITA, but instead of keeping the uploaded files I could move them to other directories before the next attempt, and getting them all listed upfront would certainly make this possible… but definitely not easy. I still think I would like a mode in which I could just run “dput *es” in a directory until it doesn’t upload anything anymore, then nuke or move the entire directory contents, much more, because otherwise it becomes difficult to decide what to move when dput errors out. (The .changes file will suffice for dput purposes, but…). I may be able to live with what you proposed, though. >suggestion. The result would be another undesirable “partial success” >result. No: if dput cannot upload anything that it’s supposed to and which has not already been uploaded, it exits nonzero, so that’s a sane failure mode, and (especially those of us in parts of the world with occasionally not-so-nice network connections) uploading stuff one after the other is certainly a valid use case, in my eyes. (My 「a mode in which I could just run “dput *es” […] until it doesn’t upload anything anymore」 modus operandi works well when you’re uploading straight from /var/cache/pbuilder/result/ **while still building more packages**, too. This can be useful. I’ve ran m68k buildms (buildd = daemon, buildm = manually ☺) this way, with a hook script that makes the content of /var/cache/pbuilder/result/ available to subsequent builds as repository as well, eliminating the need to move things away at all.) bye, //mirabilos -- This space for rent.
