? CMAKE_INSTALL_PREFIX  somewhere near the top of the  CMakeLists.txt ?

Or perhaps you can just force it in the Makefile ;>
Or export PREFIX=/usr/local

Which I have _permanently_ welded into my ~/.bashrc

Meanwhile...
In the real world.

https://lkml.org/lkml/2017/7/6/577

I now have this one bookmarked:  https://git.devuan.org/devuan-packages

I really think for this and probably anything before logins fully complete (!) we should be treating Debian like it has something contagious. (because it *has* )

Reference for sure, but sometimes its easier to start from proper upstream upstream or just belt what we have into health.

Yes that is weird mine doesn't, but I have stuff from all over the place.
I will recheck this again tomorrow or something.

I think I see the objectives.
I don't see them having to be exclusive but is  be easier that way.
I change it anyway ;>

There is no longer (in the official packages version on gitlab) any themes at all in the debian directory.
The package still installs the *sources* default though.

see: /usr/share/slim/themes/default

mkdir themename
cp default/* themename/
cd themename
change to background image as a test.

find the theme line in /etc/slim.conf
add  yourname comma,separated
or just replace it...
days of fun
AND you get to keep the default and devuan-foo if it arrives
AND the task-thing will probably overwrite the conf file !
(but you will have a backup )
FWIW:
This task-thing is probably a sane idea.
Though it needs to be more carefully implemented !

The Devuan theme login can be assured  and consistently debugged.
The branding and art folks need only grok that world.
Users can flip or even randomise from /etc/slim.conf
(if they can admin it)

There are still issues with the config file IMHO all of them quite fixable.
e.g. The session list should be generated per install from the contents of /usr/share/xsessions
(this is not such an ask for pre-install scripts)
AND OR the "sessiondir"  should be set to that directory.
(then the user needs an easy way to set a default
Finally the example ~/.xsession should be tidied up and extended to catch dbus users and stuffed in doc/exampes or something, with a note in the config.

(actually it could go system wide in /etc/X11/xsession.d with a moderate amount of work.)

Today I tested the official _stable_ _jessie_ version it can be built without consolkit (or dbus) or even the screenlock thing and with pam only. I have not bothered to fight d1h and its idea of git . Geeze you name a branch zombie and it gets all toey

(or dpkg-buildpkg s)

It works fine here stripped down like that.

(which would reduce the deps list a little as well)
If it can't find the deps it just skips that functionality where possible.
(for consolekit and pam)

Just a  passing and  thought:

I can't remeber how virtualbox works right now BUT :

If the use case is not about (emulating) architecture foreign to your systems  uname -m
try:
lxc  Linux Containers userspace tools

Its access to containers (like docker) but without the
corporate buy in ==> systemd etc

It pre-dates docker BTW.
I used to use that system for industrial strength
virtuals in my work. (with their own networks LAN and Public)

There is an entire suite of commandline tools
and *templates*,
which are not hard to bend into something else.

lxc + debootstrap  = almost anything linux you want.

People run ubuntu under debian and other "interesting" things.

They even work on RapberryPIs

Though sure, you _would_ want to be tight about that.

Think a chroot / jail  with its own network stack and process isolations.
Its more or less endless.

Then again you may know all this and have run screaming away in the past

Worth a thought though.
Not nearly so versions dependant.
2.8+ from my memory and most generic kernels will auto mount the namespaces etc.
(pfft when I was a boy ...)

Quite happy to start again all the way from the original source if needs be.
I think I understand the concept of having desktop-base installing  the theme.
Please read on as it _will_ break, unless you turn Devuan into a desktop distro.

Thoughts though: (way toooo many)

    1/ I'm probably not _atypical_ in usually doing a minimal install and adding "stuff" as needed.
        *I still don't have desktop-base installed.*
        Though sure, I'm not a majority but Desktops are not required (yet).
        Which explains some confusions ?       
   
   2/ Is slim the default official X Display Manager ?
        I'd vote yes, but assume it is.
        I'm usually suspect of C++ (opacity) but this is clear enough to grep..
        (though WTF most of the header files are trying to say ?)

        In which case /usr/share/slim/themes  should be installed by slim. 
        and then slim itself Included (required) by one of  XFCE or desktop_base ?
         (or some daisy chain)
        That way default *Desktop* installs get xfce + slim in devuan themes.
        The rest of us get a devuan themed X DM which we can break or not.

         Its not an issue to leave options disabled in the slim.conf for more minimalist users.
         I have more or less done that already.
         Importantly the THEME file has to enable features otherwise "stuff" just doesn't happen.
         Breakages _may_ lead to no login or no choice of environment, which is DM's primary purpose.

  3/ This (my) fork of slim started as an experiment really.
      I forked from helliken as it seemed to be where most of the theme works was at.
      I have no cultural memory here !
      Which is probably why it works . <==  Hellikens worked !
     
    Which leads me to:

  4/ How would one choose which fork or _reliably_ tell  which is live from the gitlab site ?
      Is there a better place to nut this out ?
      Is that what the coloured Letter symbols mean ?
      I know there is IRC but thats not everyones TZ and is an excellent adjunct.

     Perhaps I missed some memo and sailed past some docs !
     Deployed packages discuss foo: url 

     ((( If anybody tells me to trawl IRC logs  and try to guess...
     I will /dev/random their favourite USB stick ! Twice
    From my super villain base on Europa.)))
     
    Sorry I stumbled into  _all_ of this from a *github* view of *gitlab*.
    (and little experience of git going upstream!)
    I was startled when d1h stole then ate my homework !
   
   Seems to me gitlab is a good place to centre package specific discussion.
   Not BUG reports but policy / design etc.
   Its probably written some place in 72point pink letters but I can not see it .

  5/ Meantime
     What I propose I do is something like:
     

apt-get source slim -t jessie 

     Fix that here and load that on gitlab. (after it all works here)
     Then blow away my current fork.
     
     .... Use that as a base then branch (via d1h dpkg-build ) to ascii

OK it builds with d1h ...
e  v  e  n  t  u  a  l  l  y

All works OK as installed from  dpkg -i
with _its_ confs

Notes TODO etc.

However It still needs
   better visibility on F1  not hard at all
   Testing for caps lock etc

*** I need to grok why gpg  doesn't see my key , its probably something simple. ***

slim :
My own preferences would include:
  Dropping requirement for consolekit
  or dbus
       these can be run (if available) from the system xsession / xinitrd system
       per user ... but I guess that would be a bit radical

i.e. It should work with or without either of them.

Higher Priority for me:

Hack until the thing runs with other instances of X running
It silently fails if I am using :0 or any other "port" for X

Work out why some apps will launch from keyboard and not others when I use it to login

In any case these "ideas" are not for jessie   !

So far have confirmed from two fresh builds that
The following build config lets me login from DM whereas the devuan install does not.

1/ the above init hack is broken here ;> Well of course
2/This one is neater in any case

case $1 in
    start)
  #   if [ "$HEED_DEFAULT_DISPLAY_MANAGER" = "true" ] &&
  #      [ -e $DEFAULT_DISPLAY_MANAGER_FILE ] &&
  #      [ "$(cat $DEFAULT_DISPLAY_MANAGER_FILE)" != "$DAEMON" ]; then
  #      log_daemon_msg "Not starting $DESC ($NAME); it is not the default display manager." "$NAME"
  #   else
      log_daemon_msg "Starting $NAME" "$NAME"
      start-stop-daemon --start --quiet $SSD_START_ARGS
      log_end_msg $?
#    fi
  ;;

3/ have set up my own fork
    a/ for clarity sake
    b/ guess I will have to build a package at some point
        and that is best kept away from nice people. <-.->

https://git.devuan.org/PeteGozz/slim
Which should be set up to the jessie fork as default branch

4/ Builds fine :
With this wee script. (hidden by .gitignore)

#!/bin/bash
## -*- shell-script -*-

mkdir -v ./build ;
echo "$?"
cd build
pwd
echo -e "\nConfiguring cmake for PAM and CONSOLKIT\n"
sleep 3

cmake ../ -DUSE_CONSOLEKIT=yes -DUSE_PAM=yes

echo -e "\n\nCmake says :  $?\n "

make

####&& make install  by hand 
#eof

I have sussed how to use -p /to/them/dir
But haven't done any work beyond a nod to the theme .

Best plan is to "beatup" the themes  devuan-*
under debian and test that I suppose.

I'll reread the links

Bridges later and all

%% I have never used connman : %%
You probably have a working solution.
its probably /etc/resolv.conf you need to set ?
If NOT stop here :>

So Other
than seeing what :
ip r     says
and say ask the end point for a dns resolution

when it connects ($?)  and then set that address  into /etc/resolv.conf
approx...

OR
exploit the up down calls  or manual types in /etc/interfaces
and fire up a script that does it for you.
UMmmm
Roughly

So yeah these are non standard and could be some place else
These would write what YOU want in that file and maybe restore something else on interface down.
The options are optional and from my memory set in the calling environment in any case.

You could do similar when ever the connman daemon is restarted.

Whatever is easier or actually a sane solution for you.

Eventually, I guess you will need to tell routing where to go.

OR try dhclient yourInterface and hope

I have a rather over featured examples of that localscript "breakage"  here I can sanitise and post if needs be.

Use your own NIC names and addressing of course

Hey cool.
Happy 150th Canadian Cuzzes

Man 56 N that is insanely _way_ too close to any pole.
You guys must be born with glycol for blood or something.
I apologise for saying its cold. Its not even 0
Its also windy here.
Been gusting up to 100kmh in some places.

Our state is running over on 60% (ish)  wind power right now.
But I diverge digress and disintegrate 
(and way off topic)

I re-learnt some stuff I should know better about and learnt some new stuff.
So if it was help then even better.

This should not matter as Xorg accesses the devices for users.
With about 2000 qualifications it seems.

2 "engineering" moments there.
  1 By default its "slim" but as you migrated from Debian wheezy it could be whatever you had then.
  2 see the Xorg thought above.

30-mouse.conf should not be an issue. I just moved all of my /etc/X11/xorg.conf.d out of the way
and my X still works.   But please see the end of this.

Its blowing a gale here at the moment and its winter and dark and _nasty_ .

Re: evdev
Dont change anything yet.

try installing slim
ok ? NO then
try lightdm
ok ? no ?
and then
xserver-xorg-legacy
man xwrapper.config

If that dont work  I give up, for now
see post #5

-----------------
next life stuff
-----------------

OK so I went on over to the Wayland (Freedesktop) sites. (and stuff)
libinput uses evdev.
Some of  the intention is that libinput is a common protocol for wayland and Xorg.

Its essentially "just" a method to exploit the kernels exported interfaces to hardware , under /dev

By plugging the Xserver or Wayland  into them.  It also speaks evdev. (well the kernel does and libinput sees that fine)

So I went right ahead and broke my X
By installing all of that libinput backend  into my system.
Permissions fails and stuff about systemd and lots of noise in the logs...
Nothing worked not even the vesa driver !
NOTE: most of it came from ceres (unstable)
So I guess its the brave new world or something.

Sooooo then ....

I "fixed" that  by installing xserver-xorg-legacy
Which goes back to a suid xorg (xorg runs as root)
AND you need to have a  Xwrapper.config
which  allows use of this dangerous beast.

You probably still have one from wheezy.

So the easy test for installing the xserver-xorg-legacy package would be:

You can startx  as root but not as a normal user.
Its worth it as a test in any case.
Which is more or less  in my previous post #5 come to think of it .

Now here is the thing:
If it all (mouse and keys)  works as root (startx)
AND you can not use keyboard OR login (at the display manager(GUI))

Then tail the logs all you like but I would think that switching login managers is worth a try at least.

There seem to be all sorts of loginkits and handy helper do dbus whatsits breaking insidiously  all over the place. These work fine on stable / jessie  but it can all get totally silly beyond that..

So you may need a  Display Manager that supports more than just pam or more than just loginkit.
I used to trust  /etc/X11/default-display-manager (which was just whatever was installed last)
slim used to work here but on stable / jessie . Try slim first.
Then (apparently) lightdm works as it knows about dbus loginkit and pam (it seems).

Or just don't use one at all.
startx or even  xinit -- :1     

(I dont use one anymore but not for the reasons here)

dist-upgrade WILL install extra packages.

I'm guessing but its possibly because xfce => task-*-desktop  (something) pulls it in.
network-manager has a long rev depends list.

(there is probably a more elegant method)

If you can purge it without uninstalling half your system
then do that and try:
(you don't really need most desktop meta-packages any more)

/etc/apt/preferences.d/network-messwithya

that looks something like this:

Package: network-manager
Pin: release o=Debian
Pin-Priority: -15

Package: network-manager
Pin: release o=Devuan
Pin-Priority: -10

test with

$ apt-cache policy network-manager
it *should* report no candidates
e.g.

[root@lenny]: /etc/apt/preferences.d$ apt-cache policy network-manager
network-manager:
  Installed: (none)
  Candidate: (none)
  Version table:
     1.8.0-5 -10
        500 http://au.mirror.devuan.org/merged ceres/main i386 Packages
     1.6.2-3 -10
        500 http://auto.mirror.devuan.org/merged ascii/main i386 Packages
     0.9.10.0-7+devuan1 -10
        990 http://packages.devuan.org/devuan jessie/main i386 Packages
        990 http://auto.mirror.devuan.org/merged jessie/main i386 Packages

Then when I try to install:

[root@lenny]: /etc/apt/preferences.d$ apt-get install network-manager
Reading package lists... Done
Building dependency tree
Reading state information... Done
Package network-manager is not available, but is referred to by another package.
This may mean that the package is missing, has been obsoleted, or
is only available from another source

You _may_ have to do the same for gnome-network-manager
OR try a regex match

i.e. /network-manager/  *should* match any version.

(and if I were you I would do something similar for grub)