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 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.