kicad-developers team mailing list archive

[Carsten Schoenert <c.schoenert@xxxxxxxxxxx>]

Am 12.04.18 um 17:18 schrieb Reece R. Pollack:
> The KiCad 4.0.7 Debian Linux package installs files in these directories:
> 
> /etc/profile.d
> /usr/bin
> /usr/lib/kicad
> /usr/lib/python2.7/dist-packages
> /usr/share/applications
> /usr/share/doc
> /usr/share/icons
> /usr/share/kicad
> /usr/share/menu
> /usr/share/mime
> /usr/share/mimelnk

I know this, as I do this for Debian. ;)

> That's "spread all over the file system" in contrast to my preference of 
> having all installed files under one directory.

Your personal preferences are colliding with the LFS and FHS, all the
directories above are defined by them and the KiCad packages are comply
with. All those folders are quite not interesting for normal users
without system privileges and users definitely shouldn't change here
anything. We need to talk about how the possibilities are user can
override files from the packages without conflicting with them. So I
don't see your point here.

> But as I said, putting everything under one directory hierarchy (for 
> example, "/opt/kicad5") would be a significant change in behavior.

You can use this folder in your own, but for all Debian based distros
this is a no go.

> A 
> reasonable alternative is to install using file and directory names 
> which include the major version number. Thus
> 
> /usr/bin/kicad4
> /usr/bin/kicad5
> 
> and
> 
> /usr/lib/kicad4/plugins/
> /usr/lib/kicad5/plugins/
> 
> I could even accept keeping the V4 file and directory names as they are 
> and merely appending a 5 to the new files and directories.

Currently I don't see a real need to make the old version 4.0.7
co-installable. This version is about 1.25 years ago from today with the
last point update about 7 months ago.

Making KiCad 5 and KiCad nightly installable (on Linux) in parallel
isn't that difficult. You need to adjust only the desktop files for the
various application.

But the internal logic of KiCad for searching libraries and
configuration is something that's need to be done by the developers.

> I know many Windows programs install in self-contained directory 
> hierarchies now, as the previous behavior of overwriting DLLs in shared 
> directories caused major headaches. I do not develop for Windows, 
> though, so I'll leave that to those who are more familiar with that 
> environment.

Windows uses a different mechanism of symbol lookups so it's a home made
problem on Windows based platform if you have to deal with that
platform. Most applications are simply ship their own dll files to get
the horse ridden.

So far I remember a good explanation about the voodoo on windows system
can be found in the book 'Autotools: A Practioner's Guide to GNU
Autoconf, Automake, and Libtool' from John Calcote.

> https://www.amazon.com/gp/product/1593272065

...
> I'm well aware of the purpose of update-alternatives; I'm quite familiar 
> with both its use and its implementation.
> 
> Allow me to quote from the first paragraph of the link you provide:
> 
>     Here are some notes on |update-alternatives| and some examples
>     demonstrating its use. The purpose of the update-alternatives
>     utility program is to manage, on a single machine, serveral versions
>     of programs that all provide the same functionality.
> 
> That is exactly what we're doing here: managing several versions of 
> programs that all provide the same functionality.

No, we don't. And we don't need this. The whole thread is about
installing various versions of KiCad in parallel and also be able to
start them independently.

update-alternatives is simply to provide a common name that is pointing
to a real binary. The only use case could be to provide a name 'kicad'
that would pointing to 'kicad5' e.g.

Do we really need this? I don't think so.

> Nothing in either the 
> implementation nor the intent of update-alternatives requires that the 
> different versions behave identically.
> 
> A common case in the life of a developer is to have multiple versions of 
> the Gnu C/C++ compiler installed. Perhaps new development is done with 
> the GCC-5 compiler so it is the default on a system, but when producing 
> an update for older systems the GCC-4.8 version is used. The 
> update-alternatives allows the system manager to configure the system so 
> the "cc" command invokes the latest-and-greatest, but the older versions 
> are accessible by using the full file name.
> 
> Here's the path the system follows to find the proper program to run for 
> the "cc" command on my system:
> 
>     /usr/bin/cc -> /etc/alternatives/cc
>     /etc/alternatives/cc -> /usr/bin/gcc
>     /usr/bin/gcc -> gcc-5
>     /usr/bin/gcc-5
> 
> Using update-alternatives properly would require renaming the V4 files 
> to include the major version number, as well as naming the V5 file 
> properly. Perhaps there could be a 4.0.8 release that does this for 
> coexistence.

No, not needed.

ln -s /usr/bin/kicad /usr/lib/kicad/kicad

vs.

ln -s /usr/bin/kicad /usr/lib/kicad5/kicad5 ???

It's already done for the runtime libraries of the applications

> $ ls -l /usr/bin/*.kiface
> lrwxrwxrwx 1 root root 26 Apr  8 12:55 /usr/bin/_cvpcb.kiface -> ../lib/kicad/_cvpcb.kiface
> lrwxrwxrwx 1 root root 29 Apr  8 12:55 /usr/bin/_eeschema.kiface -> ../lib/kicad/_eeschema.kiface
> lrwxrwxrwx 1 root root 29 Apr  8 12:55 /usr/bin/_gerbview.kiface -> ../lib/kicad/_gerbview.kiface
> lrwxrwxrwx 1 root root 35 Apr  8 12:55 /usr/bin/_pcb_calculator.kiface -> ../lib/kicad/_pcb_calculator.kiface
> lrwxrwxrwx 1 root root 27 Apr  8 12:55 /usr/bin/_pcbnew.kiface -> ../lib/kicad/_pcbnew.kiface
> lrwxrwxrwx 1 root root 30 Apr  8 12:55 /usr/bin/_pl_editor.kiface -> ../lib/kicad/_pl_editor.kiface



-- 
Regards
Carsten