I appreciate your efforts to find a permanent solution to have a desktop working without consolekit and policykit-1 and I thank you for your desire to do everything possible so that the problem does not recur in the next release.

It seems to me that this topic has not had much participation in the forum. I do not have understand if the topic affects most users. So I will not add anything else.

Since I would like to share some other useful information with you, I will send you an e-mail as soon as possible.

I thank all those who have somehow participated in the discussion.

You're too polite! I won't put my version of that statment in print, because it's not safe for work.

I've spent a good part of the morning looking at dependencies of different display managers and session managers in jessie and ascii. It's a big rat's nest. It looks like the problem comes from a change in the dependencies of libpolkit-gobject-1-0 and libpolkit-backend-1-0.

I will discuss this with the appropriate devs, and we should be able to sort it out for beowulf.

In a modern Desktop "to allow the [normal] user to perform several typical tasks without requiring administrator privileges, including suspending/rebooting shutting down the system, mounting external devices, configuring networking, and so on" (I cite from Ascii Release_notes), a lot of software was created (mainly by freedesktop.org), in my opinion, very complicated and difficult to manage.

I refer to slim/lightdm (DM), policykit-1, consolekit, gvfs, udisks2, pulseaudio, et cetera.

This software, if properly installed and configured appropriately, allows even to an user with a very poor knowledge of Linux, to perform with a few mice clicks the operations listed above (but only in a standard way!).

I am convinced that for users who have sufficient OS experience (such as the majority of Devuan users), this software offers no advantages.

This is because if you want things go as you like, you have to master it very well. It is better to perform the above operations from a root terminal with scripts or with a few commands. In the Unix-like OS these operations are root prerogatives and these programs are designed to make them accessible to a normal user.

This is the idea that I have done in recent years. It's a personal opinion that I practice daily. So I avoid installing software that I don't I feel the need.

To respond more directly I say that consolekit is an important part (not the only) of the software that allows a user to perform operations related to management of the hardware: all together, consolekit, policykit-1 and the DM, not just one of them! gvfs, policykit-1 and udisks2 allow to manage the devices mounting to the simple user. These operations are performad by programs started by the login manager (root) and communicating via dbus with the DE. It is a complicated "mechanism" difficult to understand and control!

I do not have the right knowledge to comment on the other statement:

Consolekit, policykit-1 ed il login manager are dependent on each other and all togheter communicate via dbus. In post # 16 I wrote:

We need to know in detail how this software is built to propose an appropriate solution. Only those who know and manage these packages can find the better answer.

Unfortunately my English is poor and doesn't allow me to express myself adequately. I hope that what I wrote is understandable!

campus, can you list the functions that are lost by installing without consolekit?

Why don't you plead your case to the developers directly by submitting your comments/solution to bugs.devuan.org.  Or better yet, explore how you yourself could provide a package(s) that would allow for the removal of these components.   We're all in this together so we welcome more hands on deck.

After installing the XFCE4 components that interest us and that do not contain dependencies from consolekit/elogind, proceed as follows for "xfce4-session" package (that depends on consolekit/elogind):

• Download the packages (or altenatively the i386 version):
         a) xfce4-session_4.12.1-3+devuan1_amd64.deb
         b) libpolkit-gobject-consolekit-1-0_0.105-18+devuan2.11_amd64.deb

• Edit the xfce4-session package above downloaded, remove the dependency from libpolkit-gobject-1-0 and save it with the same name.

• Edit the libpolkit-gobject-consolekit-1-0 above downloaded, remove the dependency from consolekit and save it with the same name.

• Install the two packages modified with the command: dpkg -i .

Now it is possible to start XFCE4 with the "startxfce4" command. The desktop works normally like in Jessie, obviously without the features provided by consolekit and policykit-1.

There is an inconvenience: Because the two packages do not conform to the contents of apt-cache, if you upgrade the system them will be updated with those of the Devuan depository (which contain consolekit).

To remedy this problem: before upgrading, remove them (dpkg -r) and install them again after the upgrade (dpkg -i).

There is certainly a better and more elegant solution. But we need to have some knowledge and experience that, unfortunately, I do not have!

Who is capable, wants and can, signals to the developers of Devuan the impossibility for how the libpolkit-gobject-1-0 package is built, to use XFCE4 without installing consolekit/elogind. It is against the software freedom principle: we must not force anyone to use unwanted software! I hope they take this into account and that the next release (beowulf) no longer presents the problem!

That's all folks!

You did a great job to help me, but it was enough to tell me that it was possible to start the XFCE desktop using the instructions:

instead of "xfce4-session". I put these instructions in  ~/.Xsession file and the desktop starts without problems. Unfortunately some features are not present due to the absence of the session manager (xfce4-session).

These days I'm learning to edit .deb packages because it's my intention edit the Ascii xfce4-session.deb package to make it identical to Jessie's package, eliminating consolekit/elogind dependencies.

Yesterday, instead of XFCE4, I installed openbox and lxpanel: everything works fine. Although consolekit/elogind is installed with lxpanel, then it can be removed because, for lxpanel, it is a recommended not mandatory package.

So, in my opinion, it is sufficient to make the consolekit/elogind package recommended for "xfce4-session" instead of mandatory. I hope I can do it.

I will keep you informed of the result.

Still many thanks for your help.

Anyway, I did get xfce running without any *kits and without xfce4-session in ascii. There may be better ways to do this, but this is mostly working. I doubt that there will be any changes in xfce4-session in ascii, but it might be possible for beowulf. If you start testing beowulf, you could file a bug report against xfce4-session to get things moving.

I started with a refracta-nox install in virtualbox. (standard system utilities plus some extras, no X)
Added the following packages (without Recommends):

xorg xinit xserver-xorg-legacy xfwm4 xfwm4-themes xfconf xfce4-panel xfce4-settings xfdesktop4 xfce4-terminal thunar thunar-volman

Added needs_root_rights=yes to /etc/X11/Xwrapper.config

Put the following (exactly as posted) in /etc/X11/Xsession.d/31nokit

xfwm4 &
xfce4-panel &
xfdesktop

Start the xsession as user with startx /etc/X11/Xsession

To end the xsession, I've been dropping to console and running 'init 1' as root. I'm sure there are better ways to do this, but this is convenient for testing.

Since I have not installed a DM, of course I use "startx" to start X server, but to start the desktop, in the .Xsession file there must be "startxfce4". That I know, this is the only method to start xfce. Unfortunately, "startxfce4" is installed with xfce4-session.

I know very well Openbox and lxpanel, I used them for a long time before moving to xfce4.

I'm in no hurry to migrate to Ascii. In Jessie Xfce it works great without consolekit, policykit-1 and even gvfs and udisks2. There are still two years before jessie is no longer supported. I hope that during these two years, the installation of consolekit/elogin will be modified and/or that it is possible to remove it. Software freedom is one of the principles for which Devuan was born.

I take this opportunity to thank you for creating refractasnapshot/installer. I use it for a long time (I still keep and use an Ubuntu-12.04 snapshot!). In these years it was really very helpful and saved me so much effort! really many thanks!

Since I do not know, nor did I find anywhere else, another method to start the desktop, I wrote that the only solution possible is to modify the "xfce4-session" package.

The command you're looking for is startx. That's a generic command that will start an xsession with your default window manager. In this case, xfwm. You'd probably need to start the panel or other parts of xfce separately. I don't know exactly what limitations there would be, and I've been mostly away from the computer and unable to try it myself.

I can second the recommendation for openbox. I use it in some installations along with lxpanel. (tint2 is another popular panel.)

and yestrerday:

I add today: xfconf xfdesktop4 xfwm4 xfce4-panel packages can be installed without problem and not contain dependencies from consolekit/elogind. But "xfce4-session" is essential because the desktop is started with "startxfce4" which is installed with "xfce4-session". Since I do not know, nor did I find anywhere else, another method to start the desktop, I wrote that the only solution possible is to modify the "xfce4-session" package.

The statement of golinux:

is unjustified and the result of his imagination.

I thank Ogis1975 for his suggestion.

The desktop packages I'm interested in (XFCE4) are built so that a Session manager is always installed.

You would probably have better luck if you stopped trying to install xfce4, which is a metapackage that does nothing but pull in other packages such as xfce4-session, which you do not want. Install the parts of xfce that don't pull in the session manager, as I described earlier in this thread.

Indeed, that 'should' work.  I suggested it - more than once IIRC - but don't think (s)he ever tried it.