Buildroot Archive on 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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox