Spksrc: Git package doesn't create symlink

[bittner]

The Git package installs Git, but seems to fail to create a symlink at /usr/local/bin to make the binary available from the path. This has been described and discussed in https://github.com/SynoCommunity/spksrc/issues/3375#issuecomment-407362958.

Setup

_Package Name:_ Git
_Package Version:_ v2.15.1-11

_NAS Model:_ 918+
_NAS Architecture:_ synology_apollolake_918+
_DSM version:_ 6.2

Expected behavior

Executing git in an SSH session should show the output of Git's textual help screen,

Actual behavior

The command git is not found.

Steps to reproduce

_1._ Install the Git package on your NAS
_2._ Activate SSH, and login to your NAS
_3._ Type in git and press the Return key

[BenjV]

Why should a simlink be added to a Synology System folder, that is very bad practice which contaminate the OS.
Also after an upgrade of DSM is will be gone.
All well build packages who uses git will know where git for DSM is installed namely in the place where all well behaving packages are located.

You constantly seem to forget that DSM is not build for the commandline, but only for the GUI.

[bittner]

What would your proposed solution look like? Leave it as it is?

Git is a command line tool, isn't it? In the Unix spirit, tools (or humans) using it shouldn't have to guess where it is installed.

[BenjV]

Yes it will be left as it is.

A Synology Nas is not designed to be used as a linux server, it is a Nas based on linux with the ability tot host packaged applications.
No users will use the commandline.
The applications that uses git, knows were to find it, so no problem there.

Just like all consumer routers or even tv's that are all based on linux.

People who do use the commandline on a NAs normally know where to find everything.
Nobody uses a commandline on them, just the GUI.

[ymartin59]

In fact it has already been accepted with #2771 but discarded when migrating to generic installer at #3090.

[bittner]

@ymartin59 If this makes sense, as described in #2771, and is also the behavior of the Git Server package, then this is really a regression introduced with #3090, which needs to be fixed again, isn't it?

How can this behavior be added with the generic installer? Is there any hook that can be run at the end of a successful installation?

[BenjV]

Don't you ever read what people write in response to you questions?

If a simlink was added during the installion of git, this simlink would be gone when DSM is updated.
It is just a bad idea to add something to the system folders of DSM.
And DSM is less forgiving for tempering with the system with every new release.
We saw that with the problems that arised using busybox instead of the syno tools.

DSM and SynoCommunity packages are not for use with the commandline!!!!!!!!!!!!!!!!!!!!!

[bittner]

@BenjV I understand your point on the importance of DSM updates. So, how do we have to install Git to fix the regression from #3090? IOW, what is the approach (proposed by Synology) to make the binary be available in the path, as with the Git Server package (which is obviously configured correctly)?

[bittner]

As from the source code of the Git Server package the INSTALL_PREFIX may be relevant for correcting the issue:

INSTALL_PREFIX = /usr/local/$(SPK_NAME)

If it works this change shouldn't upset anyone, is a clean approach and sufficiently self-explanatory.

[BenjV]

The issue does not need any correction, just because you would like to have it.
And Synology does not have an approach for this, because there is no need for this functionality at all.

The git server package is not yet converted to the new framework.
As soon that is done it will behave the same as the git client.

[DKeppi]

In the nano package you also link it correctly at postinst script, why not at this git package?
https://github.com/SynoCommunity/spksrc/blob/master/spk/nano/src/service-setup.sh

[BenjV]

Nano is a package that can only be used via the commandline mainly for system maintenance, not for regulair users.
The git client is ment to be used by other packages that can be run from source like all python applications and has no use for system maintenance.

[bittner]

Can you give us a definition of "regular user"? Is a software developer using Windows a "regular user"? Or someone using Homebrew on a Mac? Can people using an Ubuntu desktop be classified as "regular users"?

This is a serious question. I think your answer is important to be able to understand your reasoning. I'm looking forward to it.

[BenjV]

It is quit simple, a Synology Nas and the SynoCommunity packages are developed for use with a Gui and it is not a general purpose linux machine.
So that's the target of these packages and if you want it any other way, feel free to do on your own Nas what you want but don't try to force your own personal preference on to everybody.

This Community is doing things for the general user and is not acting on single whishes from one or two individuals.

[bittner]

This Community is doing things for the general user and is not acting on single whishes from one or two individuals.

Well, we're actually 3 in this issue. You're one.

don't try to force your own personal preference on to everybody.

I believe, we all just try to make the Syno packages better. No-one of us is - I believe - trying to do harm to anyone or abuse this project.

We all have bought the NAS from Synology, now we want to get the best out of it. In the best interest of everyone. And, specifically to this issue: How much is a GUI user disturbed by software functioning after Unix ideals under the hood? Probably zero.

I feel very sorry for this community. :disappointed:

[BenjV]

You are the only one that want this, so do it for your own Nas.

The point is not this issue, but changing packages everytime somebody wants something that is of no use for the general user is simply to much work.
There are other matters more pressing to spent time on.

[sciurius]

Git is installed in /usr/local/git.
As many other tools do, the symlink could/should be placed in /usr/local/bin. This will not be affected by DSM updates.

[DidierLoiseau]

I am also trying to use git from the command line, _for maintenance purposes_. Granted, this is for my personal NAS at home.

Here is my scenario:

1. I have installed a SynoCommunity package that simply clones a repository from GitHub;
2. The name of the GitHub repository has changed, and the application is not able to update itself anymore (using git);
3. I would like to use the git command-line tool to change the remote.

I was a bit surprised not to find it on the path, especially since the git package description says nothing about being only “_ment to be used by other packages that can be run from source_”. On Linux it is quite standard for all command-line tools to be available on the path by default when installed from packages, so I thought something was wrong with my setup.

Fortunately, when Googling “synocommunity git package”, this issue was in the top 10 results.

[BenjV]

Synology designed the Nas as a full gui system and not as a commandline linux box.
Learn to live with it, and if you are knowledgably enough to use the commandline you could als use the full path to the package or create a simlink yourself in the shell you are using.

By the way the problem you describing seem to me the SickRage issue where echel0n hijacked the GitHub.
Only changing the git remote won't fix this.
I have created a special SickChill package, which will import the old config, database and image cache,
and adapted them to be correct again.

You can download that package her:
https://github.com/BenjV/SYNO-packages/blob/master/SickChill%20noarch%20V1.1.spk
Stop the old SickRage (if still running)
Install the package manually and run it.
Open it and check if it is ok, if so uninstall the old SickRage package.
Please hurry because SickChill will change the database layout very soon and then my package cannot do this trick anymore.

[bittner]

In all politeness, a few questions:

• Where do you take the information from for the conclusions you take? You don't work with Synology, do you? -- Do you have an official source for what you're stating?
• What is your motivation for the solid resistance against changes that would make the software better? Apparently, there are people that care about "fixing" the current behavior.

It feels a bit like you're taking the community hostage, but I may be misunderstanding your good intentions.

[BenjV]

Not sure what you mean by "taking the community hostage".
I just vouw my opinion on the subject.
My feeling in this is that you reject the fact that somebody has a different opinion on things then yours.

And DSM is a full gui system and the Linux version Synology installs on it is stripped from many tools that are normally present on a Linux distribution.
On such a system it is not wise to change systemwide things, but just do things needed for a specific package.
Like for example using a virtual python environment in stead of installing lots of site-packages on a the standard python environment.

[DidierLoiseau]

Only changing the git remote won't fix this.

Indeed, I also changed the git url in config.ini. It worked like a charm (didn't check without doing both changes though).

[bittner]

I figured out the Git 2.15.1-11 Git community package installs git as /usr/local/bin/git correctly. The actual problem is that non-root users don't seem to have their PATH variable point to that location by default:

$ echo $PATH
/usr/bin:/bin:/usr/sbin:/sbin

In other words, the only problem is that the user's PATH variable is not initialized as this is usually done. You can fix this by simply adding a ~/.bashrc file to the home directory of your login user with:

export PATH="$PATH:/usr/local/bin"