>>> Yes, both.  Report upstream and patch it in Debian until they fix it.
>>> /usr/bin should only contain executables, nothing else.
> 
>> I reported the problem upstream, but it looks like it will be addressed
>> post-release as it's not a critical issue.
> 
> I agree.  But it should be fixed in Debian regardless.

Ok. I'll look into it.

>> You're still referring to the plugin locations, yes?
> 
> I'm talking about making the main executable a symlink into /usr/lib/kicad/, 
> so
> that it will hopefully use that location as the default for its plugins.  It
> works for Python programs, but it's unlikely to work in this case.

Ah, now I see your point.
I don't think that will work, as it would require the loader to dereference
the executable path.

The plugin loader probably uses a hardcoded path, so changing that should be
much more "proper". We do the same for the symbol/footprint libraries.

>> i18n and all the libraries live in their own repositories now, and they are
>> updated independently from the main KiCad code base. So, stuffing the
>> libraries into kicad-common package will tag them with the main KiCad package
>> version, which does not accurately reflect their actual revisions.
> 
> Yes, if they have their own release schedule, they should be in a different
> source package.

Putting all the subprojects into their own package with their own packaging
scripts is a bit overkill, I think. It could make sense for the libraries, as
those are updated often. But the documentation and i18n should be aligned with
KiCad itself, even if they don't have proper release tagging. We can always
bind the source checkout to a specific revision to have consistent package 
builds.

I'll ask the kicad-doc and kicad-libraries developers if they're planning to
make releases in line with KiCad.

As for the *.pretty libraries, it would make the most sense to maintain them
separately. They are meant to be updated from inside KiCad, but Debian users
will appreciate having a system-wide package that apt can update.

> I'll have a look.

Thanks!

Attachment: signature.asc
Description: OpenPGP digital signature

Reply via email to