Re: Package Option naming: support to build with vs. default to build in

To: tech-pkg%netbsd.org@localhost
Subject: Re: Package Option naming: support to build with vs. default to build in
From: Thomas Klausner <wiz%NetBSD.org@localhost>
Date: Thu, 10 Aug 2017 22:59:05 +0200

On Thu, Aug 10, 2017 at 10:31:08PM +0200, Edgar Fuß wrote:
> > Can you enable all renderers by default, and just make an option for
> > the default? Then users could install an alternate renderer separately
> > at a later time.
> Do you want a cups-filters package that always depends on ghostscript AND 
> poppler AND cairo AND mupdf AND acroread?

No, but does it need to depend on either of the packages just to have
support for them?
 Thomas

Follow-Ups:
- Re: Package Option naming: support to build with vs. default to build in
  - From: Edgar Fuß

References:
- Package Option naming: support to build with vs. default to build in
  - From: Edgar Fuß
- Re: Package Option naming: support to build with vs. default to build in
  - From: Thomas Klausner
- Re: Package Option naming: support to build with vs. default to build in
  - From: Edgar Fuß

Prev by Date: Re: Package Option naming: support to build with vs. default to build in
Next by Date: Re: Package Option naming: support to build with vs. default to build in
Previous by Thread: Re: Package Option naming: support to build with vs. default to build in
Next by Thread: Re: Package Option naming: support to build with vs. default to build in
Indexes:

Home | Main Index | Thread Index | Old Index