All of lore.kernel.org
 help / color / mirror / Atom feed
From: Yann E. MORIN <yann.morin.1998@free.fr>
To: buildroot@busybox.net
Subject: [Buildroot] [PATCH 1/1] package/postgresql: needs wchar
Date: Thu, 15 Nov 2018 17:59:03 +0100	[thread overview]
Message-ID: <20181115165903.GL10271@scaer> (raw)
In-Reply-To: <20181101223046.72222a3c@windsurf>

Thomas, All,

On 2018-11-01 22:30 +0100, Thomas Petazzoni spake thusly:
> On Tue, 23 Oct 2018 19:04:26 +0100, Arnout Vandecappelle wrote:
> >  It is not strictly needed, but it is still useful to have it because:

I agree with Arnout here.

However, from a purely pragmatic point of view, I see that it is totally
useless in practice, so I would not mind we drop them.

And in retrospect, I think it *is* better that we do drop them. If the
top-level option loses that dependency, then it is 'easy' to detect it
has become mandatory for a sub-option, because the autobuilders will
fail.

However, if we repeat the dependency and the top-level option lses it
and we forget to remove it, we will never realise that the sub-option
shouldalso lose it.

> True. In this case:
> 
>  - Bernd did not propagate the dependency to p?p, qt and qt5base, which
>    all three are also directly selecting BR2_PACKAGE_POSTGRESQL
> 
>  - A number of places where BR2_PACKAGE_POSTGRESQL is selected do not
>    have the !BR2_STATIC_LIBS dependency.
> 
> I am really wondering what to do with those "useless" dependencies in
> general. On one hand, I agree with you that semantically, it is better
> to have them. On the other hand:
> 
>  - It's an additional maintenance burden.
> 
>  - It's never tested by the autobuilders, because such "useless"
>    dependencies are well, useless, because they are hidden by another
>    higher-level dependency. Because they are not tested, they are often
>    wrong and not maintained.
> 
> Due to this, whether we propagate them or not is completely random
> currently through the Buildroot tree, and I'm not sure it's a very nice
> situation.

I agree with you. Whatever we choose, we should do it consistently.

Regards,
Yann E. MORIN.

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 223 225 172 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'

  reply	other threads:[~2018-11-15 16:59 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-10-23 16:09 [Buildroot] [PATCH 1/1] package/postgresql: needs wchar Bernd Kuhls
2018-10-23 17:25 ` Adam Duskett
2018-10-23 18:04   ` Arnout Vandecappelle
2018-11-01 21:30     ` Thomas Petazzoni
2018-11-15 16:59       ` Yann E. MORIN [this message]
2018-11-16  8:24         ` Thomas Petazzoni
2018-11-20 18:35           ` Yann E. MORIN
2018-11-01 21:28 ` Thomas Petazzoni

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=20181115165903.GL10271@scaer \
    --to=yann.morin.1998@free.fr \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.