Jimmy Kaplowitz <[EMAIL PROTECTED]> writes: > Choice 2: Use the same source package for both althea and > althea-ssl. [...] 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.
I'm not sure of the fact that people in Russia, China, et al have no
access to non-US CDs (maybe their governments even like the title
better <g>). Does anybody have concrete knowledge in this regard?
> 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.
That's against policy (IMHO, it's not explicit). Here are the relevant
paragraphs:
In addition, the packages in main
* must not require a package outside of main for compilation or
execution (thus, the package must not declare a "Depends",
"Recommends", or "Build-Depends" relationship on a non-main
package), [...]
Since policy talks about "main" and "non-US/main" as separate
entities, I do not think that "main" includes non-US in the above
sentence. Later:
[...] A package containing a program with an interface to a
cryptographic program or a program that's dynamically linked
against a cryptographic library should not be distributed via
the non-US server if it is capable of running without the
cryptographic library or program.
Note the /if/. See also bug #95146 for a similar case with postgresql.
> 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.
Since libssl is still in a non-US section, they can simply omit that
from their configuration to never make this mistake.
--
Robbe
signature.ng
Description: PGP signature
