[Buildroot] [PATCH 1/1] package/python-pycups: new package

[Thomas Petazzoni <thomas.petazzoni@bootlin.com>]

On Tue, 25 Aug 2020 13:55:36 +0300
Asaf Kahlon <asafka7@gmail.com> wrote:

> On the other hand:
> * Differently from other packages that duplicate the "depends on",
> here we show nothing in case BR2_PACKAGE_CUPS isn't selected, so we
> should at least add a comment.

We don't always add a comment when the dependency is obvious. For
example, all python-<foo> packages don't have a comment that says
"python-<foo> needs python", because it's obvious if you want a Python
module that you need to enable Python.

> * In my opinion, even if the user knows that python-pycups needs cups,
> he wouldn't want to select it on his own and expect it to be selected
> when choosing python-pycups.
> But I agree that in some cases it's not so critical.

I think we agree that there is no clear cut line when it comes to using
"depends on" vs. "select" in this sort of situation.

What I believe is true is:

 - We want to use "select" when the dependency is non-obvious, like
   package "baz" depending on libxml2, openssl and libzorglub. We
   cannot expect the user to easily figure out those dependencies.

 - We want to use "depends on" for architecture
   dependencies/limitations, obviously.

 - We want to use "depends on" when the user has to be aware of the
   dependency, or when the dependency cannot easily be lifted. For
   example dependency on toolchain features: glibc/uclibc/musl,
   threads, etc.

For the other cases, there's no clear cut strategy. But for example
cups-filters has a "depends on BR2_PACKAGE_CUPS", with no comment about
this because we assume this is obvious. However, all other dependencies
of cups-filters are properly enabled using "select" as they are
non-obvious. Same for the hplip or gutenprint packages.

Thomas
-- 
Thomas Petazzoni, CTO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com