Leon Breedt <[EMAIL PROTECTED]> writes: > > Regarding curl, I'll be packaging an SSL enabled version only, as it seems > that policy doesnt cover a source package building for both US & non-US.
There are a couple packages which do this, mutt-i etc. I think they all make some minor alteration like touching a file and then rebuid and upload to nonus including a complete duplicate of the source package. I struggled for a while to build nonus versions of fetchmail and zephyr build against kerberos, but couldn't do it to my liking. Too many tools assumed they could run over debian/control and pick out package names themselves and too many assumed that every package listed in debian/control should be built. Really someone should come up with a single library of debian/* parsing routines, preferably compiled into a library which could be linked into perll a bash builtin module, dpkg-deb, and whatever else. Then everyone would use the same parsing routines to access these files. If a new feature is needed then it could be added to one place. Well, that's just a thought, there are disadvantages to that approach too. But I found it very frustrating at the time. Incidentally Just because the binary can't be exported doesn't mean the source can't be exported. fetchmail and zephyr, for example, include only hooks for authentication. Absolutely no hooks directly to encryption. (I think.) So there's no reason the source shouldn't be exportable. The resulting binary would have "hooks" in the form of dynamic linking to the encryption routines though... greg