John Goerzen <[EMAIL PROTECTED]> writes: > I will, however, not be applying your patch. Ignoring the return value > from 'darcs add' is worse than the problem you are describing, in my > opinion.
If someone does want to apply it until this gets a better fix, they should apply both the updated patch. > I might suggest that a workaround is to alter the darcs boring file so > that you don't have this issue. You are saying that all files in the source directory should be admitted to package.upstream? I take it that one mode of operation of darcs-buildpackage is to create a tarball from package.upstream. So that tarball would contain all the cruft upstream might have left in a snapshot that has been imported? I suppose dbp-importorig could pass a --boring switch through darcs_load_dirs and get all the files, thus avoiding this issue. (I'm sure there are better ways of working with darcs in the Debian environment than using dbp-importorig to load package.upstream from a darcs repo! I'm still working out what best practice might be. You certainly wouldn't want to try importing _darcs!) As I understand things, when dbp-importorig runs for the first time, createRepo calls darcs to initiate it and creates the 'boring' file under _darcs in mypackage.upstream. It then adds the files. So there isn't a chance to modify that boring file, and I'd have to set up a ~/.darcs/boring to handle this situation, which would affect all my other darcs inits. But as I said, I don't consider skipping a boring file to be an error. Quoting the darcs manual, "The boring file is used to filter the files provided to darcs add, to allow you to use a simple darcs add newdir newdir/* without accidentally adding a bunch of object files." So it seems a darcs misfeature to exit abnormally when no files were added, because it might just have been one boring file that was attempted under program control. -- KBK -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
