Re: USA crypto rules and libssl-dependent packages
Thank you all very much for replying. I am torn between three avenues that I am
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