From: Yann E. MORIN <yann.morin.1998@free.fr>
To: buildroot@busybox.net
Subject: [Buildroot] [PATCH 00/10] infra: add solution to dump metadata from packages (branch yem/misc)
Date: Thu, 11 Apr 2019 23:20:02 +0200 [thread overview]
Message-ID: <20190411212002.GG2539@scaer> (raw)
In-Reply-To: <20190411192651.5196cd1c@windsurf.home>
Thomas, All,
On 2019-04-11 19:26 +0200, Thomas Petazzoni spake thusly:
> On Sun, 7 Apr 2019 13:51:06 +0200
> "Yann E. MORIN" <yann.morin.1998@free.fr> wrote:
>
> > This series is a proposal to allow extracting metadata about packages,
> > in a way that makes it reusable for tooling outside of Buildroot, that
> > is both reliable and extendable, without causing too much burden on
> > Buildroot own infrastructure.
>
> Overall, I am quite happy with the general idea (as we have already
> discussed). It allows to extract a lot of information about the
> packages, in a format that is easily parseable.
>
> My small annoyance is that we start to have some overlap between the
> following mechanisms:
>
> - The "make printvars" mechanism, which essentially already allows to
> dump the metadata of all packages. Admittedly, in a format that is a
> lot less nice. I think this overlap is OK, since "make printvars" is
> mainly intended as a debugging mechanism, not so much as a real tool
> whose output can be parsed. The new JSON stuff could presumably be
> used as a replacement to "printvars" for people who need to
> currently parse the "printvars" output.
I don't see printvars and show-info to compete against each other.
Instead, printvars is indeed more about debugging Buildroot, or poking
at internals. That really what it is: dumping Buildroot internals; there
is no guarantee about its stability, i.e. it is not an API of some sorts.
show-info, on the other hand, really exposes metadata so that it can be
consumed by external tooling provided by the user, and for which we
actually want to expose that data in a reliable and stable way.
> - The "make legal-info" mechanism, which also outputs some metadata
> about the packages.
When I wrote show-info, I realy pondered whether to expose the licensing
information or not, because of legal-info, and maybe I should have
refrained from doing so, with it maybe as an addition in the future.
legal-info does not print much information, though. It does collect that
information and makes it available for the user in the form of a
directory with source code, license files, and so on...
But I don't see putting the source code, the license texts and all the
content of legal-info/ into the JSON output, while the license list is
toally trivial.
I also pondered adding the licenses for the dependencies in
foo-show-info, but I did not do so, on the assumption that users who
want to make use of it would anyway have to write their JSON extractor,
in which case they would be able to very easily generate the
licenses-of-dependencies.
> I'm not at all saying that we shouldn't merge this JSON output, I just
> wanted to point out the different ways that already exist to extract
> some package metadata out of Buildroot.
Well, my idea wuld maybe to actually phase-out those rules, or at least
base them on this new JSON output.
Heck, even graph-depends could use that instead of the recently
introduced show-dependency-tree, and this is what I was going to do
before the release, so that show-dependency-tree never ever gets into
a release.
Regards,
Yann E. MORIN.
--
.-----------------.--------------------.------------------.--------------------.
| Yann E. MORIN | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software Designer | \ / CAMPAIGN | ___ |
| +33 561 099 427 `------------.-------: X AGAINST | \e/ There is no |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL | v conspiracy. |
'------------------------------^-------^------------------^--------------------'
next prev parent reply other threads:[~2019-04-11 21:20 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-04-07 11:51 [Buildroot] [PATCH 00/10] infra: add solution to dump metadata from packages (branch yem/misc) Yann E. MORIN
2019-04-07 11:51 ` [Buildroot] [PATCH 01/10] infra/pkg-download: return just a list of URIs Yann E. MORIN
2019-04-07 12:20 ` Thomas Petazzoni
2019-04-07 12:42 ` Yann E. MORIN
2019-04-07 11:51 ` [Buildroot] [PATCH 02/10] infra/pkg-download: make the URI list a callable macro Yann E. MORIN
2019-04-10 8:33 ` Thomas De Schampheleire
2019-04-07 11:51 ` [Buildroot] [PATCH 03/10] infra/pkg-download: get rid of the FLOCK variable Yann E. MORIN
2019-04-07 11:51 ` [Buildroot] [PATCH 04/10] infra/pkg-download: make the DOWNLOAD macro fully parameterised Yann E. MORIN
2019-04-07 12:46 ` Yann E. MORIN
2019-04-07 11:51 ` [Buildroot] [PATCH 05/10] infra/utils: add helper to generate comma-separated lists Yann E. MORIN
2019-04-10 9:03 ` Thomas De Schampheleire
2019-04-07 11:51 ` [Buildroot] [PATCH 06/10] infra/pkg-generic: introduce foo-show-info Yann E. MORIN
2019-04-10 9:16 ` Thomas De Schampheleire
2019-04-11 20:49 ` Yann E. MORIN
2019-04-11 17:33 ` Thomas Petazzoni
2019-04-13 8:58 ` Arnout Vandecappelle
2019-04-13 17:17 ` Yann E. MORIN
2019-04-13 19:07 ` Arnout Vandecappelle
2019-04-07 11:51 ` [Buildroot] [PATCH 07/10] infra/pkg-generic: introduce foo-show-recursive-info Yann E. MORIN
2019-04-10 9:20 ` Thomas De Schampheleire
2019-04-07 11:51 ` [Buildroot] [PATCH 08/10] infra/fs: introduce rootfs-foo-show-info Yann E. MORIN
2019-04-10 9:19 ` Thomas De Schampheleire
2019-04-07 11:51 ` [Buildroot] [PATCH 09/10] infar/fs: introduce rootfs-foo-show-recursive-info Yann E. MORIN
2019-04-10 9:19 ` Thomas De Schampheleire
2019-04-07 11:51 ` [Buildroot] [PATCH 10/10] infra: introduce top-level, global show-info Yann E. MORIN
2019-04-10 9:28 ` Thomas De Schampheleire
2019-04-11 21:06 ` Yann E. MORIN
2019-04-13 9:08 ` Arnout Vandecappelle
2019-04-10 12:47 ` [Buildroot] [PATCH 00/10] infra: add solution to dump metadata from packages (branch yem/misc) Thomas De Schampheleire
2019-04-11 17:26 ` Thomas Petazzoni
2019-04-11 21:20 ` Yann E. MORIN [this message]
2019-04-13 8:00 ` Arnout Vandecappelle
2019-04-13 17:19 ` Yann E. MORIN
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=20190411212002.GG2539@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