Re: [Buildroot] [PATCH 1/1] package/qbee-agent: new package

From: "Yann E. MORIN" <yann.morin.1998@free.fr>
To: Arnout Vandecappelle <arnout@mind.be>
Cc: "Buildroot Mailing List" <buildroot@buildroot.org>,
	"Jon Henrik Bjørnstad" <jonhenrik@qbee.io>,
	"Christian Stewart" <christian@aperture.us>,
	"Anisse Astier" <anisse@astier.eu>
Subject: Re: [Buildroot] [PATCH 1/1] package/qbee-agent: new package
Date: Sat, 11 Nov 2023 09:35:29 +0100	[thread overview]
Message-ID: <20231111083529.GJ996011@scaer> (raw)
In-Reply-To: <c394918d-edcc-4d52-9a0d-727ece0cd394@mind.be>

Arnout, Christian, Jon, All,

On 2023-11-10 20:28 +0100, Arnout Vandecappelle via buildroot spake thusly:
> On 10/11/2023 18:14, Christian Stewart via buildroot wrote:
> >On Fri, Nov 10, 2023, 2:45 AM Jon Henrik Bjørnstad <jonhenrik@qbee.io
> ><mailto:jonhenrik@qbee.io>> wrote:
> >    This patch add qbee-agent, an open source device management software
> >    for Linux devices.
> >Are there any buildroot users today who would want to install this package
> >with it's proprietary backend independently of using the proprietary
> >backend?
> >
> >Who holds the private key for that public key and what can they then do
> >with my device if I chose to install this package?

Those are valid questions, but they are to the user who builds a rootfs
with qbee-agent to assess. If they _need_ qbee-agent (for whatever
reason, good or bad), then it is available in Buildroot.

As Yann@work pointed out however, is that we need to have a little
explanation on what the key is, and whether users may need to have their
own, and why the key provided in this patch differs from the one in the
github repo, and what the comment in the github repo is about.

> >This seems like a case where, if I was adding this package for a
> >proprietary service, I would instead opt to use a Buildroot External
> >Package for the reasons stated above:
> >https://buildroot.org/downloads/manual/customize-outside-br.txt
> ><https://buildroot.org/downloads/manual/customize-outside-br.txt>

Not really. br2-external trees are made for packages one does not want
to be public, i.e. the packages themselves are internal to one's org.

> >Indeed: there are many cases like this one where I'll maintain an external
> >buildroot extensions tree because the packages are not fully open source
> >(backend and frontend) and therefore probably not of interest to the main
> >buildroot user base.
>  I don't think "open source agent for a closed-source backend" means that we
> don't want to carry it in buildroot. In fact, we have at least one of those
> already: azure-iot-sdk-c. I'm sure there are others.

The point I was about to make.

It would be a bit sad indeed to not have a open source implementation fo
the server side, or that users can't specify an alternate provider (i.e.
choose to run their own), but that's orthogonal to having the client in
Buildroot.

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.  |
'------------------------------^-------^------------------^--------------------'
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot