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. |
'------------------------------^-------^------------------^--------------------'
next prev parent 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