On 04/12/18 09:58, Carsten Schoenert wrote:
Hi,

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 reality.

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

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

/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.

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
strategy, though.
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 environment.



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"
commands.
updates-alternatives has a different approach as you think. It's not
designated for this solution you think off.

http://williamdemeo.github.io/linux/update-alternatives.html

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
   /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.

_______________________________________________
Mailing list: https://launchpad.net/~kicad-developers
Post to     : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Reply via email to