On 04/12/18 09:58, Carsten Schoenert wrote:
Am 12.04.2018 um 15:47 schrieb Reece R. Pollack:
I'm a relative newbie to KiCad, but I've been a software engineer since
the early 1980. I'd prefer to see KiCad installed in a self-contained
manner, meaning all installed files end up under one directory hierarchy
rather than being spread all over the filesystem.
well, KiCad isn't installing "some there" and "all over" the various
systems. If you think so you have a impression that is different from
The KiCad 4.0.7 Debian Linux package installs files in these directories:
That's "spread all over the file system" in contrast to my preference of
having all installed files under one directory.
But as I said, putting everything under one directory hierarchy (for
example, "/opt/kicad5") would be a significant change in behavior. A
reasonable alternative is to install using file and directory names
which include the major version number. Thus
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.
This is how Xilinx
ISE, Eagle, and many other packages are installed, and it makes it very
easy to keep multiple versions. This would be a major change in
If all software projects would follow the common rules on the various
platform it would be easier for all. But especially Windows based
software follows often some "own" rules as it's simply possible.
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
Regardless, I agree that file names or paths should include the major
version number. The executable file "kicad" should be renamed "kicad5"
for V5. The directory under /usr/lib and /usr/share should be renamed
from "kicad" to "kicad5". And so on. Under Linux (or at least the
Debian-derived distros) the "update-alternatives" utility can be used to
select which version is run using the "kicad", "pcbnew", and "eeschema"
updates-alternatives has a different approach as you think. It's not
designated for this solution you think off.
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. 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
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
Mailing list: https://launchpad.net/~kicad-developers
Post to : firstname.lastname@example.org
Unsubscribe : https://launchpad.net/~kicad-developers
More help : https://help.launchpad.net/ListHelp