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

[Carsten Schoenert]

Hello Brain,

Am 15.12.20 um 06:32 schrieb Brian Holaday:
> Hi Team,
> 
> I know that I am not much help here as of yet but have any of you looked
> at (https://koji.fedoraproject.org/koji/buildinfo?buildID=1524434
> <https://koji.fedoraproject.org/koji/buildinfo?buildID=1524434>) as far
> as building.

Rock Storm and also myself have looked at this resource, simply to see
how other distributions support Arduino.
I think the support of Arduino is only done seriously within Arch and
Fedora for now. But both distributions doing it differently with
different naming of the packages. Looking at the structure Arch has
chosen I think this reflects the needed package relations best by
fulfilling the KISS (Keep It Stupid Simple) principle.

https://www.archlinux.org/packages/?sort=&q=arduino&maintainer=&flagged=

> I also don't know if there has been any support in adding
> (https://www.microchip.com/mplab/mplab-x-ide
> <https://www.microchip.com/mplab/mplab-x-ide>) - MPLab X as an option
> for installing?

The MPLAB IDE isn't something that I need urgently so I never did looked
at this before you mentioned it here.
Its' not unsolvable but the kind of distribution of this IDE is exactly
the way of providing a big binary blob that makes it hard to even create
a non-free package within Debian. I've stopped looking at this more in
detail after seeing a big shell script with more than 1GB of size which
still requires sudo privileges.

> Right now I am actually testing (Ubuntu and Fedora) to see what distro
> long term I might stick with. Seems like Fedora is more updated but I
> have yet to test any of the electronics packages but I wish more support
> was driven in these packages here but I also know it's challenging to
> find time. A clear example is I still have some KiCad model work pending
> in the KiCad main repo.

You don't need to have a status of an active DM or DD to support Arduino
(or other) packages. We also need users that do caring about the
usability of packages, which have a good understanding how the things
work together and report and interact with the Maintainers. For sure
it's mostly helpful if you are experienced with packaging, but it's no
hard requirement. Solving packaging issues is more a really good
knowledge how your local system is working.

Contributing is also participate in decision taking processes, which you
do right now by writing down your thinking and minds about certain packages.

-- 
Regards
Carsten