It was used solely by the make_rpm machinery. With that one gone we can
drop the script.

The script seems outdated (no support for zstd modules) and
undocumented. If we are to revive it (no objections there) we should
address those two as a base acceptance entry.

Signed-off-by: Emil Velikov <[email protected]>

A while ago we started using os-release to get the distribution
name/details. Since then all the distros that I've seen (apart from
Debian and derivatives) have dropped lsb-release from their
dependencies.

Let's remove the final remanands, this in turns allows us to remove the
special PATH mangling and the unmaintained in-tree lsb_release (see next
commit).

As a nice bonus - source the /etc/os-release in a sub-shell, so we don't
get any other control flow/variables as side-effect.

Signed-off-by: Emil Velikov <[email protected]>

The codebase has moved to use /etc/os-release with a fallback to
lsb_release. That said, the latter has two variants a data file in /etc
or an executable in $PATH.

The in-tree lsb_release is an executable script, although it's installed
outside of $PATH and no distribution (that I can see) adjusts the
environment variable or even uses external lsb_release dependency.

Considering the lack of practical users, let's remove the script. We can
worry about the remaining in-tree lsb-release references later on.

Signed-off-by: Emil Velikov <[email protected]>

Signed-off-by: Emil Velikov <[email protected]>

mkdir inherits the umask of the environment. Using install gets us past
that, while also being consistent with the rest of the codebase.

Signed-off-by: Emil Velikov <[email protected]>

There are dozen of instances across the codebase, that use /var...
although none of them actually honour the variable. Skimming through
existing projects/distros - they all seem to use the default.

Inline the instance and print a meaningful error in case it's set.

Signed-off-by: Emil Velikov <[email protected]>

There are dozen of instances across the codebase, that use /etc...
although none of them actually honour the variable. Skimming through
existing projects/distros - they all seem to use the default.

Inline the instance and print a meaningful error in case it's set.

Signed-off-by: Emil Velikov <[email protected]>

There are dozen of instances across the codebase, that use /usr...
although none of them actually honour the variable. Skimming through
existing projects/distros - they all seem to use the default.

Inline the instance and print a meaningful error in case it's set.

Signed-off-by: Emil Velikov <[email protected]>

The uncompressed manual is absolutely tiny, plus the decision to
compress or not is up-to the distribution. In cases where people
build/install dkms manually they can handle this themselves.

For example: Gentoo has a workaround to remove the compression
@AndrewAmmerlaan - you can now drop that \o/

Signed-off-by: Emil Velikov <[email protected]>

There is a single instance of the variable, there's no Linux
distributions that I can see overriding the default. Yet most
importantly the variable should really be called MANDIR, to be
consistent with the vast majority of projects out there.

BSD, Solaris and friends tend to use different path, but dkms is not
usually used on those.

As needed we can reinstate the config toggle (as MANDIR really) if
needed.

Signed-off-by: Emil Velikov <[email protected]>

Usual conventions dictates that DESTDIR is applied at the install stage.
We currently embed it into each use-configurable toggle, which goes
against that.

Signed-off-by: Emil Velikov <[email protected]>

AFACIT no linux distro out there uses the non-default values. Similar to
MAN - some BSD/Solaris distros might have differing path. Although until
that proves to be an issue, let's remove these.

Signed-off-by: Emil Velikov <[email protected]>

Usual conventions dictates that DESTDIR is applied at the install stage.
We currently embed it into each use-configurable toggle, which goes
against that.

Signed-off-by: Emil Velikov <[email protected]>

The current all target is a bit bonkers - it cleans all the generated
files, does not explicitly regenerate them and creates a distribution
tarball.

With the latter having the side effect of regenerating the required
files, by having a dependency list.

Similar to the tarball target, install also has an explicit dependency
list of files that need to be generated.

All of this is fairly uncommon to how all the projects (that I've seen)
operate. Namely:

all: all_the_generated_targets

install: all
   install steps

tarball: all

clean:
   foobar ... the target is never a dependency of any of the above

Signed-off-by: Emil Velikov <[email protected]>

If the user has provided SBIN we should honour it.

The Makefile handling is a bit repetitive, but polishing that is an
exercise for another day.

Signed-off-by: Emil Velikov <[email protected]>

Usual conventions dictates that DESTDIR is applied at the install stage.
We currently embed it into each use-configurable toggle, which goes
against that.

Signed-off-by: Emil Velikov <[email protected]>

If the user has set LIBDIR we should honour it.

Signed-off-by: Emil Velikov <[email protected]>

Usual conventions dictates that DESTDIR is applied at the install stage.
We currently embed it into each use-configurable toggle, which goes
against that.

Signed-off-by: Emil Velikov <[email protected]>

If the user has set KCONF we should honour it.

Signed-off-by: Emil Velikov <[email protected]>