Buildroot Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
To: buildroot@busybox.net
Subject: [Buildroot] [PATCH 2/2] libvncserver: add config option for tightpng encoding support
Date: Sat, 27 Dec 2014 19:07:55 +0100	[thread overview]
Message-ID: <20141227190755.10b11f1c@free-electrons.com> (raw)
In-Reply-To: <549EEFCC.9030202@je-eigen-domein.nl>

Dear Floris Bos,

On Sat, 27 Dec 2014 18:43:40 +0100, Floris Bos wrote:

> Do note that the only thing using PNG inside libvncserver is the 
> TightPNG encoding.
> Think it is a bit counter-inductive to give users TightPNG support, just 
> because another package selected libpng, even though they chose not to 
> select the TightPNG feature.
> 
> (Just like I believe it is counter-inductive that users are expected to 
> know which dependencies are needed to get a specific feature they want, 
> as seems to be the current case with many buildroot packages, which do 
> not offer any feature options).

This topic has been the source of many discussions in the Buildroot
community, and we're trying to find a balance between two options:

 * Have sub-options in each package for all the various possible
   optional features they have. This makes it more explicit for users,
   but on the flip side generates a huge maintenance burden, as we
   would have a much much larger number of Config.in options to
   maintain.

 * Make optional features automatically enabled. This is less explicit
   for users, but it is sometimes good (like if you have OpenSSL
   enabled, enable SSL support everywhere it is possible), and avoids
   creating zillions of Config.in options.

So generally, on a case by case basis, we decide which of the solution
is the most appropriate. Sometimes the latter is good enough and avoids
creating more Config.in options, sometimes the former is really
necessary to make it explicit to the user what is happening. I don't
think it is possible to settle on one or the other solution and apply
this decision unconditionally to all packages.

Best regards,

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

  reply	other threads:[~2014-12-27 18:07 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-12-26  0:46 [Buildroot] [PATCH 1/2] libvncserver: bump version to 0.9.10 Floris Bos
2014-12-26  0:46 ` [Buildroot] [PATCH 2/2] libvncserver: add config option for tightpng encoding support Floris Bos
2014-12-26 17:08   ` Thomas Petazzoni
2014-12-26 17:37     ` Floris Bos
2014-12-27 13:51       ` Thomas Petazzoni
2014-12-27 17:43         ` Floris Bos
2014-12-27 18:07           ` Thomas Petazzoni [this message]
2014-12-26  4:40 ` [Buildroot] [PATCH 1/2] libvncserver: bump version to 0.9.10 Baruch Siach
2014-12-26 15:03   ` Floris Bos
2014-12-26 15:16     ` Yann E. MORIN
2014-12-26 17:07 ` Thomas Petazzoni
2014-12-27 13:52 ` Thomas Petazzoni
2014-12-27 17:01   ` Floris Bos

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20141227190755.10b11f1c@free-electrons.com \
    --to=thomas.petazzoni@free-electrons.com \
    --cc=buildroot@busybox.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox