On Mon, May 14, 2001 at 10:32:07AM +0200, Robert Bihlmeyer wrote:
> Jimmy Kaplowitz <[EMAIL PROTECTED]> writes:
>
> > 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.
>
I agree it is against policy if I leave althea in main, but if I take Choice 3
I would move it to non-US. I guess I wasn't clear enough.
I still am not sure what to do though, but I am leaning toward Choice 3. The
biggest problem with that choice that I see now is that people who don't have
non-US in their server list would never find out about my package, all because
of the optionally-compiled-in IMAP-over-SSL support.
- Jimmy Kaplowitz
[EMAIL PROTECTED]
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
