← Back to team overview

kicad-developers team mailing list archive

Re: Broken default fp-lib-table, removed footprint library

 

On 12/05/2020 09:40, Carsten Schoenert wrote:
Hi,

I started to package the updated packages due the tagged KiCad 5.1.6
release and started alphabetically with the footprints as this is the
first directory locally.

More by an accident I noticed that the directory
Connector_Multicomp.pretty is now empty. Digging into the reason behind
that I can see that the whole content of this folder has moved into
Connector_IDC.pretty.

I see there multiple issues here.

1. For me this is a breakage (again) of the rule no changes within the
stable release cycle on the user side that can break user projects and
workflows.
Compared to a classical C/C++ library would this be a removal of a
public symbol without an wrapper for backward compatibility, means an
API/ABI break which requires a increasing of the ABI version.
What is broken here? The old library folder is still there to ensure users do not get an error message. Footprints are embedded in the design files so no negative impact on old designs. The new footprints are vastly superior to the old ones so the tradeoff is simply worth it!
2. The default footprint table (fp-lib-table) within the tagged 5.1.6
tree is still referencing the old folder so user get this installed as
the default base for their footprint library table if they install a new
KiCad version or enforce a new default table.

$ git grep -n Multicomp fp-lib-table
fp-lib-table:28: (lib (name Connector_Multicomp)(type KiCad)(uri ${KISYSMOD}/Connector_Multicomp.pretty)(options "")(descr "Multicomp connector foottprints"))
Keeping that entry makes no sense to me if the folder is now empty.
Yes we could remove the entry but our CI script would complain -> so we decided to just have the empty lib it does not hurt anyone.
3. KiCad still has no internal mechanism to handle such removals within
the user space to adjust the local footptint table. Package
installations / removal doesn't touch or modify any user specific
configuration files so manual interaction from the user is needed to
adjust such cases.
Adding such an feature is not the responsibility of the library
maintainers of course, but makes such changes more difficult and
problematic within a stable release cycle. (And of course I don't want
to blame any one here!)
Well now you know why we keep the empty folder. (At least v5 does no longer crash with a missing lib.)

4. I haven't found a README or otherwise announcement about this change.
Also the commit message f764afb in kicad-footprints is rather short and
not explaining to me.

This all did already happen previously in 2017 in the releases of 4.0.5
and 4.0.7. At least two bug reports within Debian did happen due these
changes as this was leading to a breakage on the user side and also
leading to bad user experience.

https://bugs.debian.org/859409
https://bugs.debian.org/860093

In the past "we" solved the issues by adding symlinks from the old to
the new containing folder. Currently I'm undecided what to do here in
this new case.

Anyhow, please don't do such changes within a stable release cycle! It's
o.k. to do such things within major version bumps (as at some time it
must happen) but not within an increased *micro* version!
People do not expect such changes. And the majority of user isn't
following the development of KiCad itself or the libraries in deep! Keep
that in mind please. Thanks.

The two bug reports you list again clearly show why we now keep the libraries as empty instead of removing them.


Follow ups

References