[Pkg-electronics-devel] Updating Arduino UI and related package dependencies, what blockers do we have?

[Carsten Schoenert]

Hello Rock,

Am 12.12.20 um 12:18 schrieb Rock Storm:
...
> I wouldn't worry too much about getting it into Bullseye.

of course not as there is always the way through backports.

> We should work on it regardless of the release cycle. If we could get
> Arduino 1.8.13 working in Debian that'd be a huge achievement given
> where we are now. If we could get it in time for the next release,
> it'd be amazing, but I'd be very happy with just getting it in at
> some point.
Exactly, I'm happy if we can come to some movement into a forward
direction.

> As for arduino-builder, I gave up last year after getting no support
> from the Go Packaging Team team to get the new dependencies into the
> system [1][2]. Hence why arduino-builder has not been updated since
> then. I'm happy to try again and/or let anyone with more experience/time
> to spare to take over the package.
> 
> [1]: https://lists.debian.org/debian-go/2019/07/msg00007.html
> [2]: https://lists.debian.org/debian-go/2019/07/msg00008.html

Ahh, o.k. I was thinking about such a reason why it was in stuck.

Regarding new B-D I figured out these three packages.

> diff --git a/debian/control b/debian/control
> index de1ab70..cfa1a47 100644
> --- a/debian/control
> +++ b/debian/control
> @@ -12,7 +12,10 @@ Build-Depends: debhelper-compat (= 12),
>                 golang-github-arduino-go-timeutils-dev,
>                 golang-github-fsnotify-fsnotify-dev,
>                 golang-github-go-errors-errors-dev,
> +               golang-github-iancoleman-orderedmap-dev,
> +               golang-github-pkg-errors-dev,
>                 golang-github-schollz-closestmatch-dev,
> +               golang-github-sirupsen-logrus-dev,
>                 golang-github-stretchr-testify-dev,
>                 golang-google-grpc-dev,
>                 golang-goprotobuf-dev

But more I wasn't able and willing test because it was becoming to much
and fragile without asking other involved people.
I've no idea how often the two (or more) Arduino Go packages needing an
update, it might doable if we start to take care on these packages on
our own and ask for help again once we facing new and deeper issues. But
first we need a plan it all as you've written further down.

>> 2. We need a new package arduino-core-avr to fulfill a new dependency of
>> split of AVR stuff from arduino-core.
> 
> As for the AVR stuff, as was suggested by Leonardo, I started looking
> at how Arduino is packaged in Fedora. Instead of an 'arduino-core-avr'
> source package, the 'arduino' source package provides the binary
> 'arduino-devel' package which seems to provide more or less the same
> content(?). Maybe anticipating future introduction of new cores(?). So
> basically their 'arduino' source package recklessly aggregates all
> arduino libraries and cores. I'm not saying this is the right way to do
> it, and I'm not saying I'm against an 'arduino-core-avr' package, just
> wanted to point out that a different approach is done there.

Yes, I was also thinking about some new source package structure due the
new situation right now. But I have no complete overview how the various
parts are needed to interact. We should start a new wiki page or enhance
and use the existing one to collect the things, otherwise it will become
cumbersome quickly to go through an email thread again and again.

> Other concerns I have, please forgive my ignorance here:
> 
> 3. Arduino seems to ship custom versions of avr-gcc and avrdude. I have
> not investigated what the differences (if any) are. But this could mean
> that certain code compiled in Debian produces different results if
> compiled using the standalone app provided by Arduino. Maybe Matthijs can
> shed some light here. Cause ideally Arduino should use the system
> gcc-avr and avrdude packages already present in Debian.

I can fully understand why Arduino is doing this, but as you also
explain for one reason we don't want this and we don't need to follow
that way. Of course this could be less painful to do if upstream is
willing to hear our concerns and is helping sometimes so we as Debian
can provide packages for users that produce the same outcome in the end.

> 4. I'd say there's a fair risk of this package becoming a sort of a
> dependency hell given the amount of little dependencies it has. So I'd
> suggest investing some time in planning the packaging strategy and also
> getting the commitment from a team to maintain it cause it probably
> won't be a 5-minute-job.

Fully correct. And that was one of reason why I started this thread
here. We should revisit everything we have right now and ask our self if
the structure is till useful and correct. Otherwise it will become
rapidly tedious to work on needed package migrations.

> 5. And last but not least, I think it is not a problem but users could
> quite easily install non-FOSS libraries for whatever closed-source
> components they are using on their projects. I believe as long as we
> don't ship these libraries the package is fine, but I'm raising the issue
> just in case anyone has concerns about this.

This point was Matthijs already mentioning within the licensing thread
on GitHub for ArduinoCore-avr and I agree on this. We should invest our
time in the parts of software that is clearly free and also nearly easy
to handle. OTOH we can also provide non-free packages if this is
sensible and helpful for users.

-- 
Regards
Carsten