kicad-developers team mailing list archive

["Reece R. Pollack" <reece@xxxxxxx>]

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.