From: "Roberto A. Foglietta" <roberto.foglietta@gmail.com>
To: Henning Schild <henning.schild@siemens.com>
Cc: Jan Kiszka <jan.kiszka@siemens.com>,
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 23:44:46 +0100 [thread overview]
Message-ID: <CAJGKYO48sxpi+28bsx4UQr7vkmy3R+SaRucYF5OxtiQCbyTxMA@mail.gmail.com> (raw)
In-Reply-To: <20230202211419.4188241f@md1za8fc.ad001.siemens.net>
On Thu, 2 Feb 2023 at 21:14, Henning Schild <henning.schild@siemens.com> wrote:
>
> Am Thu, 2 Feb 2023 20:06:12 +0100
> schrieb "Roberto A. Foglietta" <roberto.foglietta@gmail.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.
>
> All EXTRA_ARGS switches are very dangerous because they allow very
> unintended hacks. We have several of them and some of them have caused
> some serious fun. Especially if people use them "code-injection-style"
>
> like EXTRA = "; true; sudo fun"
>
Some people might play funny tricks in their projects and no one could
prevent this but what has to do with ISAR? Why do we need to worry
about that? Overloading the class or function would not allow them to
play any trick they want? They can append or prepend whatever they
want in every class and every function they want. Why are extra
arguments variables such a problem and :append or :prepend or
.bbclassappend are not?
Best regards, R-
next prev parent reply other threads:[~2023-02-02 22:45 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
2023-02-02 20:14 ` Henning Schild
2023-02-02 22:44 ` Roberto A. Foglietta [this message]
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=CAJGKYO48sxpi+28bsx4UQr7vkmy3R+SaRucYF5OxtiQCbyTxMA@mail.gmail.com \
--to=roberto.foglietta@gmail.com \
--cc=henning.schild@siemens.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