Handling sym-lib-table when using gitlab cloned libs instead of installed libs

I’m using Kicad 6 on a Linux machine. This posting is more like a remark/hint (that might be helpful) than a question.

In order to have sym-lib-table automatically “synced” with the state of the local git repository, I replaced the sym-lib-table (and fp-lib-table) by symlinks to the respective files in my local copy of the git repository.
However, when I create a new (global) library from within the symbol editor, it is (by default) supposed that it is stored at ~/.local/share/kicad/6.0/symbols¹. In the case of a symlink sym-lib-table, this results in change of sym-lib-table in the respository which would put the repository in the “changed” state, and as such prohibit merges. This is sort of an undesired side-effect of using symlinks.
Only after copying the library to the repository location (and after modifying sym-link-table with usage of ${KICAD6_SYMBOL_DIR}, this use case makes sense. Now I can create my own branch which additionally contains my library/libraries as well as sym-lib-table which would merge automatically when I update (rebase) my branch to a more recent upstream state.

My conclusion: under the assumption of using a symlink to sym-lib-table the usage of .local/... storage makes no sense at all.

__
Ref 1: Of course, the solution is simple: to mind that the dialog “New Library” shows this default path, which must be changed by a path to the local git repository prior to hitting the save button.

You’re trying to make a single directory do too much. ~/.local/share/kicad/6.0/symbols is meant for your private libraries and you would normally define say KICAD_USER_SYMBOL_DIR to point to it. If you use git cloned system libraries, you should put them somewhere else, say ~/lib/kicad/6.0/symbols, and define a path variable to point to it. Then you can avoid symlinks. Even though the git clone is owned by you, you should still treat it as read-only, otherwise you may introduce changes that make you get out of sync with the master repo.

That’s the reason for creating an own branch to avoid ‘sync problems’ at all.

I think the main objective in my posting is to point out a problem when a symlink to sym-lib-table from repo is used. Especially this use case with own libs results in ‘syncing’ problems. Therefore I opt for the solution to put it all into the “single directory”. Which is - by the way - located in /home/kicad/gitlibs/... in order to be independent of user.

The usage of .local/... storage for git clones makes no sense at all. It’s meant for private libraries.

There, fixed that for you.

There’s also no necessity to use the sym-lib-table (and fp-lib-table) from the git repo. You can adapt it to make a modifiable version in ~/.config/kicad/6.0/sym-lib-table and it can contain a mix of system and private libraries. That way you are not tied to a “single directory”. That’s in fact just what happens when people start off with the distro library packages and then register their own private libraries in addition.

That’s correct - thank you. I remember that in former Kicad versions I used to specifiy via “manage symbol libraries” which libraries would not be loaded upon startup because I never use some libs at all - and reducing the amount of libs also reduces loading time (in the past).

Having this capability in the GUI - to tick on or off (disable) - is alone a reason to keep sym-lib-table as a separate ‘thing’ from the libraries.
So… I’ll now think about it, whether I remove the symlinks or not (if not, I should also not tick libs as disabled). Removing symlinks has the disadvantage that I should check whether new libraries are added to any update from upstream…

Even if you want to use libraries from a Git repo, I would not advise using the sym-lib-table from the repo. I would still keep my own custom copy of a the library tables that I manually sync.

You could even create a custom hook to do a diff on the repo copy and the custom copy every time you pull, to detect upstream changes that you might want to copy over manually.