From: "Roberto A. Foglietta" <roberto.foglietta@gmail.com>
To: Jan Kiszka <jan.kiszka@siemens.com>
Cc: isar-users <isar-users@googlegroups.com>,
Uladzimir Bely <ubely@ilbers.de>
Subject: Re: [PATCH] Revert "dpkg: sbuild allows extra arguments via DPKG_SBUILD_EXTRA_ARGS"
Date: Thu, 2 Feb 2023 20:06:12 +0100 [thread overview]
Message-ID: <CAJGKYO4HPsH7J1n0dMK5Ur9oJtqSYRarnYHyek1Mu5JJBMa8QA@mail.gmail.com> (raw)
In-Reply-To: <51601d94-280d-b903-785c-3bef73f75fb1@siemens.com>
On Thu, 2 Feb 2023 at 15:42, Jan Kiszka <jan.kiszka@siemens.com> wrote:
>
> From: Jan Kiszka <jan.kiszka@siemens.com>
>
> This reverts commit 6d5fbbab9c9e3c894cbc9cf18180fb0057f82f20.
>
> There are no concrete use cases for this interface known. Adding it
> without an idea what it should be good for can create downstream
> problems as the class evolves and also motivate inappropriate use of
> this low-level interface in recipes.
Open-source is about empowering the users and unless illegal use of
it, there is no any reason to judge the use they do of it. It is hard
to think that a variable would motivate an "inappropriate use" unless
the user did not find a way to address a problem and the go to look in
that class. At that point, it might find a quick solution in that
variable without the need of overload the entire class in the top
layer and modify the class loosing the upstream updates. I agree that
there is no reason to documenting that variable. It is
self-explanatory and quick to identify for those get deep into the
dpkg class.
MHO.
Best regards, R-
next prev parent reply other threads:[~2023-02-02 19:06 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-02-02 14:42 Jan Kiszka
2023-02-02 19:06 ` Roberto A. Foglietta [this message]
2023-02-02 20:14 ` Henning Schild
2023-02-02 22:44 ` Roberto A. Foglietta
2023-02-03 18:50 ` Henning Schild
2023-02-03 20:49 ` Roberto A. Foglietta
2023-02-07 8:54 ` Uladzimir Bely
2023-02-07 9:45 ` Roberto A. Foglietta
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=CAJGKYO4HPsH7J1n0dMK5Ur9oJtqSYRarnYHyek1Mu5JJBMa8QA@mail.gmail.com \
--to=roberto.foglietta@gmail.com \
--cc=isar-users@googlegroups.com \
--cc=jan.kiszka@siemens.com \
--cc=ubely@ilbers.de \
/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