Thank you all very much for replying. I am torn between three avenues that I am considering taking.
Choice 1: Keep althea in main and make a completely separate althea-ssl package in non-US. This would allow me to provide a source package for althea that has no Build-Dependency on libssl-dev, which would be good for the people who live in countries where crypto is not allowed. However it does mean that I would have to duplicate any packaging changes I make between the two packages. Choice 2: Use the same source package for both althea and althea-ssl. This would probably mean putting everything in non-US, since the source package would be used to generate the althea-ssl package. It would require a Build-Dependency on libssl-dev, but it would nevertheless be possible for people in crypto-restricted countries to build the package by running a different target, or some such nonstandard hack. I would not have to duplicate any packaging changes between the packages. However, since even the non-crypto version would be in non-US, anyone in a crypto-restricted country who gets their .debs from CD-ROMs would probably not get any copy of althea, since they would not get the Binary 1 non-US version. Choice 3: Just change the main althea package to include ssl support, and add to the package description and README.Debian notification to that effect, with instructions on how to get a non-SSL version built. This would be simpler for me, but less convenient for users, who would have to build a non-SSL version for each new release. To alleviate this difficulty, I could offer to build a non-SSL package (a la Choice 1 or 2) if I got enough demand for it. Also, though, any users who already have the non-crypto version of althea installed and who do a blind dist-upgrade will install libssl by mistake, which could be illegal in some locales. I do intend to send BXA notification to enable me to upload to non-US despite my residence within the US. What do you all think? What should I do? - Jimmy Kaplowitz [EMAIL PROTECTED]
