Proposal to make bunsen-meta-all (and lite) init agnostic

Bearded_Blunder · 2022-01-18 03:02:36

My understanding is, that dbus-user-session and dbus-x11 are both currently specified as hard depends in order to ensure both arrive installed on a standard systemd system, however, a small tweak will see them both installed on any system that has neither, and any system that has dbus-user-session.

It's actually quite difficult to install a GUI system using systemd as init that doesn't fit that criteria, since apt preferentially installs dbus-user-session when it must provide one or the other as a depend.

To get it all working including under sysvinit a small tweak is needed to the Depends: line on control

Depends: all-previous-depends, dbus-user-session, dbus-x11, remaining-depends

Becomes:

Depends: all-previous-depends, default-dbus-session-bus | dbus-session-bus, dbus-x11, remaining-depends

Done this way it will pull in both dbus-user-session and dbus-x11 on any systemd system with neither, on systems with only dbus-user-session, it will pull in dbus-x-11, this means dbus-x11 gets installed if bunsen is added alongside *any* of the native Debian DEs (well not GNOME Flashback, since that has both anyway).

This avoids putting anything into recommends & thereby pulling in bloat when installing, interestingly when it's blocked/not installable dbus-user-session still shows up in the apt-get output as recommended during the install.

However, the metapackage remains installable even on systems where dbus-user-session is not.
See table of outcomes below:

###########################################################################
|   Debian with systemd. Presence of dbus-user-session and dbus-x11       |
|    when doing a paralell install if bunsen-meta-all (as modded).        |
|-------------------------------------------------------------------------|
| Install of task-de-desktop  |  Has dbus-user-session  |  Has dbus-x11   |
|  --no-install-recommends    |   Before   |   After    | Before | After  |
|   on CLI Only Netinstall    |   Bunsen   |   Bunsen   | Bunsen | Bunsen |
|-------------------------------------------------------------------------|
|            GNOME            |     Yes    |    Yes     |   No   |  Yes   |
|-------------------------------------------------------------------------|
|            XFCE             |     Yes    |    Yes     |   No   |  Yes   |
|-------------------------------------------------------------------------|
|       GNOME Flashback       |     Yes    |    Yes     |   Yes  |  Yes   |
|-------------------------------------------------------------------------|
|             KDE             |     Yes    |    Yes     |   No   |  Yes   |
|-------------------------------------------------------------------------|
|           Cinnamon          |     Yes    |    Yes     |   No   |  Yes   |
|-------------------------------------------------------------------------|
|            MATE             |     Yes    |    Yes     |   No   |  Yes   |
|-------------------------------------------------------------------------|
|            LXDE             |     Yes    |    Yes     |   No   |  Yes   |
|-------------------------------------------------------------------------|
|            LXQT             |     Yes    |    Yes     |   No   |  Yes   |
|-------------------------------------------------------------------------|
| bunsen-meta-all on bare cli |     No     |    Yes     |   No   |  Yes   |
--------------------------------------------------------------------------|

Now, In order to cover the situation, where someone managed to roll their own DE from scratch and somehow end up with only dbus-x11 on a setup using systemd, in spite the fact that apt installs dbus-user-session preferentially whenever it can whenever anything depends on either unless dbus-x11 is already there.

I'm not sure how they'd manage it without deliberate intervention by `apt-mark hold` or `apt-get remove`, but lets cover it anyway.

In my tests I dealt with it in the system-tweaks section of bl-welcome.

This works for me when dropped into system-tweaks between the pae check & cd install check, it's heavily commented now, which you'd obviously clean up, & my bash scripting is primitive at best, I'm more used to Windows batch/cmd scripts and not good at those either.

If you use it, you'll probably want to improve that as well, (example I tried about 9 different ways to get that apt-get install simulation on the same line as the if rather than checking $? there having run it previously, since that seems to be the style used in bl-welcome. I could *not* get the syntax right, and it breaks if you just put it there "as is" falling through to the next check regardless of result).

You'll probably want to revise the messages as well as ditching the excessive comments.

What's there appears to be fully functional though. I couldn't break it on my test systems, systemd or sysvinit. I tried every combination of present, absent, held, pinned -1, & uninstallabe there is.

# Addition as part of init cross-compatibility, check for dbus-user-session
# offer to add it if it's missing and possible to do, dbus-x11 is guaranteed to be present because of the depends.

say 'checking session bus...'
# Can dbus-user-session even be be installed? Check by simulating.
# If we don't use sudo here apt-get complains, even if it complains to /dev/null
# I absolutely needed the redirection there even with qq and sudo when I tried
# otherwise it still complains in the terminal if there's no installation candidate.

sudo apt-get install dbus-user-session -sqq 2> /dev/null 1> /dev/null
# This won't tell us if it's already installed or installed and held though.
# Exits with a status of 0 if it can be [re?]installed, & 100 if it's not
# installable. e.g. Pinned at -1, held without being installed,
# or has unmeetable deps under a non-systemd init.

if [[ $? == 100 ]]
then
	# It's not installable we're done trying - move to the next section/page.
	say $"Either you have manually pinned or held the package or else your installation"
	say $"does not support installing dbus-user-session." 2
#Next check: Is it already on the system in the normal way or on-and-held.
elif dpkg -l | grep -Eq '^ *(h|i)i +dbus-user-session'
then
	# Present. NFA needed.
	say $"You already have dbus-user-session installed." 2
# Done checking, dbus-user-session is not there and could be, offer it.
else
	say $"Your system supports the default systemd user session bus"
	say $"(dbus-user-session), but you do not appear to have it installed." 
	say $"Depending on your use case, you might, or might not, notice any difference"
	say $"with the revised security model the newer user session bus  offers."
	 
	# It's possible we could offer to put this on hold here as an alternative to installing,
	# in case the user switched on purpose, they might not want something pulling it in as a dep.
	# I didn't bother writing that, I don't think it's needed.
	
	if prompt "Would you like to install it now?"
	then
		promptTriggerInstall 'SystemD user session bus.' 'This script will install the default systemd user session bus.' 'dbus-user-session' || say 'Continuing in spite of install problem...' 2
	else
		say 'continuing...' 2
	fi
fi

That about covers all the bases I can think of right now. Done this way you can't install bunsen-meta-all or lite without pulling in dbus-x11 in addition to what you have, it pulls in both on any system with neither even before system-tweaks checks, and system-tweaks will offer dbus-user-session if it's somehow missing & not actively blocked, if it's installable at all that is.

Nothing changes for the vast majority, except system-tweaks telling them they already have dbus-user-session, everyone gets dbus-x11 because it's a hard depend, but the key plus is, it installs regardless of init chosen. Those who choose an alternative init just get told by system-tweaks their system doesn't support dbus-user-session.

You don't need a sysvinit system to test, you can easily provoke all the outcomes under systemd:

Run it on a standard Bunsen install, it'll tell you you already have it, held or otherwise.
`apt-get remove dbus-user-session`, then either pin or apt-mark hold, it'll tell you you can't install it.
Undo the pin/hold & run again, it'll put it back for you as long as you accept it.

johnraff · 2022-01-19 06:26:59

@B_B thank you for the work you've put into this.

Some thoughts:

1) I'm not 100% sure without doing more research how apt's algorithm handles the order of install from a long package list presented simultaneously. If dbus-x11 had been installed by that point, might 'default-dbus-session-bus | dbus-session-bus' not mean "dbus-session bus is provided by dbus-x11 so no need to install default-dbus-session-bus"? Is there no ambiguity?

2) The metapackages are meant to be a convenience for users who don't want to (or can't) use the iso. They're not a central part of BL. I'd have no objection to a small tweak if it could be shown not to increase the chance of obscure support issues, but making systemd optional is not a high priority when the metapackage itself is optional.

3) The welcome script is meant to help new users get their system up and running, deal with a couple of common issues, and allow them to do their studying-up later at a more comfortable pace. I don't see it having any role in helping advanced users set up specially modified systems. There'd be no end to all the little tweaks it could offer...

4) There is a much simpler option available for users who want to do a no-systemd install or otherwise tweak their system: the netinstall script. Two files pkgs-recs and pkgs-norecs can be easily opened - even by a new user - in nano and unwanted packages commented out, extra ones added. Including such instructions in a non-systemd how-to looks to me like a much more congenial option than building a chunk of code into bl-welcome that the great majority of our users will never need, but will still need maintaining. Once the Beryllium release is done the netinstall script will be gone over once more to bring it up to date.

johnraff · 2022-01-20 02:48:23

BTW @B_B if you had a list of packages to remove or replace in a non-systemd BL install, I could very easily add a section to the netinstall README explaining how to edit pkgs-recs and pkgs-norecs.

Maybe it would also be easy to add a pkgs-remove file too. The netinstall script recently has been pretty much bypassed by the metapackage for BL installs on a Debian base, but it was meant to be easily tweakable from the start, and this kind of general expansion of its customizability would open up some use-cases and looks worth doing.

Last edited by johnraff (2022-01-21 00:45:09)

DeepDayze · 2022-01-20 15:13:16

I like this as it opens up new possibilities for being able to switch to other init systems such as runit, s6, upstart as well as good ol' Sysvinit for those who don't want to mess around with systemd and its bugs that just wait to bite you at the wrong time. I would bet this sort of thing would be on a best effort basis no doubt.

Bearded_Blunder · 2022-01-20 23:58:52

Sorry, long post.

In answer to point 1. That's pretty much exactly what my understanding of what it means is. If dbus-x11 is already there before apt-get is launched to install the meta on a system without dbus-user-session, that would be how the system stayed with the deps of the bunsen metapackages as I modded, unless dbus-user-session got manually installed, or pulled in by something that had it as a depend or recommend later.

That outcome is very typical of "Debian Stable" behaviour, on a paralell install the user may already be relying on the behaviour/security model of the one they had & it would be very UnDebian to suddenly change it without warning. Testing or Sid, possibly, & that's why apt listchanges is vital in those. In Stable not as much. Pulling in d-x11 on a system with d-u-s already there shouldn't upset anything a user may have configured or expect, the documentation alleges it does nothing with d-u-s present.

Hence another reason for handling it via the check I hacked up even under systemd, you seem to feel it's really-really-really important that users get both & effectively use d-u-s, personally I've found nothing broken or dysfunctional from using d-x11 instead.

Now I couldn't tell you which is more likely to result in obscure support issues, letting the deps of the listed packages decide what's pulled in on a given system, doing what I've suggested to ensure so far as possible both are present, but with the user's consent if you're switching them, or potentially switching session bus under a user during a paralell install without warning or notice. They all seem equally likely to cause something obscure me, but the last one has the potential to make said user angry as well.

I did see there was a long discussion while I wasn't around "about which to use", & literally nobody I saw made the suggestion of "Why don't we use whatever session bus gets pulled in as depends by the specified package list on a given system? If anything lands broken, then that'd clearly be a bug in said package & would need reporting to the Debian maintainers." -- Just saying.

I've literally yet to install any sort of DE under systemd & *not have* dbus-user-session, the only ways I've managed to create the situation for my testing, is to install.. install dbus-x11 & then sudo apt remove dbus-user-session, or install cli & apt-mark hold it before putting a DE on.

Notwithstanding my point about changing the behaviour of the session bus in another environment a user might have installed without warning, if you've any suggestions how a user might manage to build a new systemd system accidentally using d-x11 rather than d-u-s, rather than it being deliberate, for the situation to arise at all, I'll go try it in a VM.

2) The metapackages are meant to be a convenience for users who don't want to (or can't) use the iso.

That's kind of my point too, anyone wishing to use an alternate init fits the second category unequivocally. They're "(or can't) use the iso", once Bunsen (or pretty much any DE) is installed you can't switch init post install (or I haven't found a way yet). I tried that earlier with a lightweight DE. Result was apt bombed out leaving me with a system that had no init at all. You also can't switch from the installer's boot parameters like you could with Jessie, well you can for command-line only installs, but that's not an option with the Bunsen iso, once a DE starts getting installed it switches you back, watched it happen (ctrl alt f4 while the installler is running).

Though judging by how many fewer packages have issues in Bullseye than did in Buster & Stretch, I think Debian are very quietly moving away from the "Systemd is mandatory." stance that seemed to infect them with Stretch.

Point 3 I get, not wanting the script to grow like topsy into something that's painful to maintain. It would be easy to do that. On the other hand this is not much code, (revised tidier version below - I didn't like needing to use sudo, least privilidge & all that, or having the test outside the if, it was messy.). It's not like the spaghetti bl-exit was growing to when I was playing with adding configs and options. You'll notice I stopped that game when you mentioned maintaining it.

The vast majority would only see "Checking session bus" "OK" go by....

say 'checking session bus...'
if [[ "$(apt-cache policy dbus-user-session | grep 'Installed:' | awk '{print $2}' - )" == "$(apt-cache policy dbus-user-session | grep 'Candidate:' | awk '{print $2}' - )" ]] || [[ "$(apt-cache policy systemd | grep 'Installed:' | awk '{print $2}' - )" == "(none)" ]]
     then
          say $"OK" 2     # Installed (matching versions). Else or not installable pinned, i.e (Version: and Canidate: both "(none)"), or not installable, unmet depend. Installed Version/Candidate will match unless manually held, we literally just upgraded.
elif [[ "$(apt-mark showhold | grep 'dbus-user-session' )" ]] || [[ "$( apt-cache policy dbus-user-session | grep 'Candidate:' | awk '{print $2}' - )" == "(none)" ]]
     then
          say $"OK" 2     # RARE: Held or Pinned by user. Deliberate. Assume they know what they're doing.
else
     # 'Installed: (none)' and there's a candidate.
     say $"Your system supports the default systemd user session bus"
     say $"(dbus-user-session), but you do not appear to have it installed." 
     say $"The default systemd version has (arguably) better features."
     # At least, that's what the systemd devs say, couldn't prove it by me....
     say $"Unless you know you have a reason not to use it, it is"
     say $"recommended you install it." 
     if prompt "Would you like to install it now?"
     then
          promptTriggerInstall 'SystemD user session bus.' 'This script will install the default systemd user session bus.' 'dbus-user-session' || say 'Continuing in spite of install problem...' 2
     else
          say 'continuing...' 2
     fi
fi

It's nice of you to suggest I may be an 'advanced user" I'm probably less so than you think, just in posession of a browser, a search engine & determination. Plus a love for Debian & loathing of systemd. Call it a dysfunctional relationship if you like.

unimportant ramblings wrote:

The PAE check is a minority thing too, not many times people are using 32 bit machines these days. Nor have ever I noticed any difference in performance between pae kernels or otherwise on any of the old 32 bit junk I own. 32 bit motherboards don't typically support enough RAM to make pae useful to begin with 32 bit server boards did, & Microsoft even enabled using pae to access it in the 32 bit server OS before server went 64 bit exclusively, but hobbled it in everything except server, & their dominance meant no incentive to make a board that'd support enough RAM to use it in anything except the server space. As the hardware situation is, even for old machines these days, probably a more useful check would be is the machine 64 bit capable & running 32, then suggest if they ever reinstall, consider the 64 bit version, it's inherantly more secure.

From the mainaining it stance, at least it's not just eye-candy like scrolling instead of clearing... which is painfully slow in my virtual machines by the way, especilly the 32bit ones, If I'm going to be waiting I'd rather have longer to read the messages personally. But then #! was a theming & config excercise on openbox, so it's understandable eye-candy gets high priority, part of the distro's heritage & it's not so bad on real hardware.

Point 4 I'm looking forward to the netinstall script being gone over, & I do get that it's easy to modify, have done so back when installing on Stretch (over Buster the metapackage installed - no mods required, but the switch itself was really painful), in Stretch network-manager required systemd, & a substitution (or omission & relying in ifup/down) was called for.
Btw, if Boron or later switch to mostly Qt because of incoming gtk theming difficulties, connman as used in LXQT looks quite nice and has plugins for extra functionality (bluetooth, vpn) available.

johnraff wrote:

BTW @H_H if you had a list of packages to remove or replace in a non-systemd BL install, I could very easily add a section to the netinstall README explaining how to edit pkgs-recs and pkgs-norecs.
Maybe it would also be easy to add a pkgs-remove file too. The netinstall script recently has been pretty much bypassed by the metapackage for BL installs on a Debian base, but it was meant to be easily tweakable from the start, and this kind of general expansion of its customizability would open up some use-cases and looks worth doing.

I think you meant B_B, no worries, they're adjacent keys. It's not like the netinstall would need any modding beyond commenting dbus-user-session if listed.

With pam_systemd.so made a symlink pointing at pam_elogind.so (even manually, not building an equivs package) I haven't found anything broken because of the switch yet once Be is installed, without the symlink the power options in the lightdm greeter are greyed out... only the act of installing itself after the switch is problematic. So modding the script & defining what changes need making is a very short project indeed.

Assuming that is d-u-s & d-x11 were listed, neither was for Lithium, I'm guessing you relied on depends to pull the bus in, (as I probably would if it were my choice for Be) & were planning to list both for Beryllium.

If you're going to list them rather than rely on them being pulled as deps, those two should probably be in their own section pkgs-auto & be pulled in with `apt-get install --no-install-recommends --mark-auto` (I think `--mark-auto` was a new c/l option in Buster).

If anything in Beryllium actually couldn't install and use dbus-x11 instead, we wouldn't be having this discussion about depends on the meta & I'd just accept the meta wasn't going to work.. as I had to when NetworkManager had systemd in its depends, though I probably wouldn't until after looking for an alternate & suggesting a substitution, even if it got shouted down.^

[edit] Pasted correct code block[/edit]

Last edited by Bearded_Blunder (2022-01-21 07:35:02)

johnraff · 2022-01-21 08:28:23

OK tl:dr at the bottom of this post is a proposal that might work. Before that, just a bit of tidying-up of details.

Point 1) is basically that when given a long list of packages to install in one command, apt and dpkg have their algorithms. We attempt to figure out what happens in certain cases, but to know exactly would require reading - and understanding - lines and lines of source code. @B_B (sorry about that typo) as you say, with Stable the devs try not to pull the rug out from under us too often, but apt's behaviour does sometimes change especially wrt subtle things like this. I don't really want to have yet another thing to follow and adjust to, when a simple Depends: A, B will cover our needs.

Bearded_Blunder wrote:

...you seem to feel it's really-really-really important that users get both & effectively use d-u-s, personally I've found nothing broken or dysfunctional from using d-x11 instead

It's not about feeling, it's because the issues have come up. d-u-s is the default for a reason: some things don't work properly without it (we had an issue with catfish). Meanwhile there are some corner cases when dbus-x11 is needed (eg running mousepad as root in the reduced-size "CD" system). Yes, you can certainly get by only with dbus-x11 and the 'dbus-launch' command it provides, but Simon McVittie explains better than I could why dbus-user-session is the preferred way.

I've literally yet to install any sort of DE under systemd & *not have* dbus-user-session, the only ways I've managed to create the situation for my testing, is to install.. install dbus-x11 & then sudo apt remove dbus-user-session

We've tried that. We tried and discussed all sorts of things (starting 2017). During the course of our discussion the landscape changed too. In the past d-u-s and d-x11 were incompatible, but now they can co-exist.

If dbus-x11 is installed alongside dbus-user-session, you're right that it "does nothing" the way that d-u-s starts a daemon, but d-x11 makes 'dbus-launch' available for those unfortunate applications that still rely on it. There are some.

...my point about changing the behaviour of the session bus in another environment a user might have installed without warning...

I'm sorry but you keep making this point about some user's carefully customized system being roughed over by a cruel and careless metapackage (or welcome script). The metapackage is not intended to be used this way. (I've said this already too.) It's a way to get a BL system installed on top of a standard Debian CLI netinstall install. An alternative path to the iso, especially useful right now when there is no Beryllium iso. Tweakers and hackers, please read my suggestion at the bottom.

I think Debian are very quietly moving away from the "Systemd is mandatory." stance that seemed to infect them with Stretch.

This may very well be the case. I think "infect" is too strong - from what I gleaned from mailing lists, there have always been a substantial number of Debian devs who wanted to keep, sysvinit at least, as a viable option.

The PAE check is a minority thing too, not many times people are using 32 bit machines these days.

Agreed. The number of i386 processors not supporting PAE is very small, but I think it was you who pointed out that a PAE kernel added nothing to really old machines, so we shipped the CD iso with a non-PAE kernel so they could boot it, then offered to put it in afterwards.

Before long we could even consider dropping 32 bit support altogether.
Maybe not just yet though...

As the hardware situation is, even for old machines these days, probably a more useful check would be is the machine 64 bit capable & running 32, then suggest if they ever reinstall, consider the 64 bit version, it's inherantly more secure.

Even on 64bit hardware, 32bit systems use less RAM and some people might deliberately be doing that. But as you say, by the time bl-welcome is running it's too late to change anyway.

...eye-candy like scrolling instead of clearing... which is painfully slow in my virtual machines by the way, especilly the 32bit ones

It's not just eye-candy - the scrolling enables you to scroll back and read previous messages, while clearing used to wipe them away - that was the main point of the change.

The scrolling speed was a compromise between people who wanted it slow enough that the user definitely saw it was a scroll and people like you who got impatient. It goes pretty fast on my VM. I don't know why yours is slow, the speed is determined by iterations of a certain fraction of a second, so the only cause could be the CPU running out of steam I guess. Not a great deal to be done there.

Assuming that is d-u-s & d-x11 were listed, neither was for Lithium

Where do you get that? dbus-x11 is listed in the Lithium metapackage (Helium too), iso install list and in the netinstall script. d-u-s might have got pulled in by some package dependency, but it's not guaranteed. I had to manually install it after upgrading a fresh Lithium VM to Bullseye.

Anyway...

Netinstall Script

The netinstall script is really pretty much a personal project, which started out as an alternative way to install CrunchBang. These days BL packages pretty much know how to look after themselves so all you have to do to get the system is install them, but the #! system did need a bit of tweaking beyond just installing the packages. So the script has much more flexibility built-in than is needed these days just for installing BL.

It might be just right, though, for someone wanting to install something close to BL on a non-standard Debian base, eg no systemd. Apart from two package install lists - with and without recommends - there is a directory tree that gets copied in before the big install, and another one afterwards. Also some system commands that run before, and some more after, the install. So there's plenty of scope for hacking without having to touch the main "install" script at all.

So if you've got the impression I'm not too thrilled about adding a lot of non-systemd options to the base BL utilities, I would rather entertain the idea of making a no-systemd branch of the netinstall script incorporating all the package choices and system tweaks needed to make it work. It would be nice for the script to have a raison d'être again.

Two conditions though:

1) I don't want to do all much of the work. I'd need to know exactly what the new installer would have to do to set this up. I am prepared to help with any tricky corners of the netinstall mechanism itself though. Looking at the files I think you (@B_B) should be able to figure a lot of it out.

2) I don't want to have to provide user support for a non-standard BL. If you started a forum thread about using the Netinstall Script to do this and were prepared to answer user questions there, then it could fly.

What do you think?

Bearded_Blunder · 2022-01-21 10:15:24

I always did like the netinstall script, I was tired when I looked at the package list looking for dbus entries, evidently I missed it, tab's still open & now when I look, there it dbus-x11 in all it's glory.. my bad.

I may well take a look & have a think, frankly it was always easier to use even on a perfectly standard system than the metapackage, wget untar & go... at the least I'm far more likely to figure that script out than the internal workings of apt to get any concrete conclusion about any subtle changes that might or might not happen.

Much as I'd like the meta to be directly installable under an alternate init, it's not an insuperable problem if it's not. Was worth a shot though. I didn't want to let it go without at least trying.

As to the scrolling, my machine is ancient, HP called it end of life in early 2010, & busy, spare steam it hasn't much of, & VirtualBox is a pig, VMWare is much more performant, but they dropped support for my processor a couple or three years & upmty versions ago. I missed the distinction with scrolling back, that is indeed useful, been so many hours at a tty I forgot about scrollback... It'll be entirely down to processor running out of steam.

Last edited by Bearded_Blunder (2022-01-21 10:27:37)

johnraff · 2022-01-22 01:24:02

OffTopic/ You might consider trying Qemu/KVM some time.
With virt-manager it's not hard to set up and might run a bit faster than VirtualBox. I'm not an expert, but I think it needs your machine's BIOS support (might apply for any virtualization though). https://wiki.debian.org/KVM

Meanwhile, do you use Git? If so, I can make a new branch, you could fork it on GitHub, make your changes and try it out, since it will be on the GitHub server for machines to download. If it works, send a Pull Request and I'll merge it in. Failing that, just tell me what changes to make to the various files. Either way, if there's an independent branch up there it will be available for testing machines to download and run. Name it "beryllium-no-systemd"?

Bearded_Blunder · 2022-01-22 02:08:55

O/T
I did try Qemu.. it's a Windows host though & Qemu is if anything even slower than VirtualBox under Windows, or was when I last tried, it's been a few years, no equivalent to guest additions either, & the clipboard integration I use all the time. Might try my luck with Hyper-V but that always used to give issues with Linux. The processor virtualization thing is required by all that I'm aware of to run a 64 bit guest, some will allow running a 32 bit guest without. I was affected by that last till I dropped in a used ebay processor upgrade a while back.

Back on.
I have never actually *used* Git, I have a Github account, made so I could post an issue with a then-under-development Yahoo! plugin for Pidgin.

Looking like I might have to learn it, currently I've about zero idea how Git is used. Once I've got the first clue, then I can look maybe into doing something similar or identical to what you suggest, but it'd be way easier once the standard version points to Bullseye, stuff in there still refers to Buster on the Beryllium branch, & getting the actual normal release ready to fly with the normal install methods is the priority at the moment.

Meanwhile I think I might be onto a potential nasty surprise with this metapackage, which would affect all users, not just the dislike systemd brigade. Frankly seeing if I'm right & investigating trumps alternate inits by some margin, if I'm right in my suspicion you'll be seeing a bug report, if none appears I was wrong.

Edit: Update, I think it was something I did, anyway I can't reproduce it again.

Last edited by Bearded_Blunder (2022-01-22 04:30:57)

johnraff · 2022-01-22 07:25:43

Bearded_Blunder wrote:

...it'd be way easier once the standard version points to Bullseye, stuff in there still refers to Buster on the Beryllium branch, & getting the actual normal release ready to fly with the normal install methods is the priority at the moment.

It is as you say.

Bearded_Blunder · 2022-01-29 11:20:56

johnraff wrote:

1) I'm not 100% sure without doing more research how apt's algorithm handles the order of install from a long package list presented simultaneously.

Just as an incidental thing I ran across while looking into runit, from the discussion in this bug which was batted back & forth between being assigned to runit, & to apt, the logic according to the apt maintainer who responded is:
If a recommend is already satisfied, apt leaves it alone.

Elseif something is going to be installed, apt preferentially installs the *first* option listed in the or, & works down second, third, etc., based off installability or availability, & installs the first listed one it can.

Now it would surprise me greatly if the same logic wasn't used for depends as recommends ....

No I'm not pushing for you to change your mind about the proposal, of course I'd be happy if you did but I'm simply supplying what seems to be apt's internal logic as reported, for your information.

Quote from https://wiki.debian.org/Init

In Bullseye, a number of alternative init systems are supported (such as System-V-style init and OpenRC).

(My bold) So it appears it's official, Debian are actually officially supporting having a choice now, which delights me I never did get on with Devuan, similar as it is...

Anyhow, I'm certainly not against the proposal to sort installing with an alternate init in use by using the netinstall, though I'm also having some success here testing a preseed from

url=http://etc.etc.tld/preseed-name.cfg  preseed-md5=the-md5-sum-of-said.cfg

supplied to a standard netinstall as boot parameters ]:D Just hacking the meta on with that horrid apt-show | grep | cut | sed game I put in my how-to.

Last edited by Bearded_Blunder (2022-01-29 11:56:32)

Bearded_Blunder · 2022-01-29 14:36:03

hhh wrote:

And a lot of non-free and contrib packages OOTB, correct. Follow suit. We use systemd, we use pulseaudio, when stable switches to pipewire we'll use that, when it switches to Wayland... we'll stay strong and carry on.

@hhh
Does that mean if Debian "officially" support SysVinit / Open RC according to their website we do too? Not to be a pain.. but "Just saying" while refering to this....

Last edited by Bearded_Blunder (2022-01-29 15:12:44)

manyroads · 2022-01-29 16:20:08

Has anyone considered using:

1. MXLinux (built using Debian Stable offering systemd & sysvint) or
2. Devuan (Debian stable without systemd but offering SysV, OpenC, Runit) ?
3. antiX might also provide a good Debian base as might
4. Artix if you wanted a non systemd arch distro.

Seems like the above might offer approaches to numerous of the issues mentioned in this thread.

Just curious.... FWIW. I am hardly capable of addressing the numerous concerns discussed in this thread.

Last edited by manyroads (2022-01-29 16:21:01)

hhh · 2022-01-30 01:14:55

@ B_Bl, we'd discuss it on the forum before doing anything. But quoting from your link...

Debian Wiki/Init wrote:

Since jessie, only systemd is fully supported; sysvinit is mostly supported, but Debian packages are not required to provide sysvinit start scripts. Support for init systems other than systemd is significantly improved in Bullseye. runit is also packaged, but has not received the same level of testing and support as the others, and is not currently supported as PID 1. As of Bullseye, a collection of sysvinit start scripts that have been removed from their original packages is provided in the orphan-sysvinit-scripts package.

So it sounds like sysvinit is making a comeback on Debian but isn't really there yet (orphaned scripts package, ouch).

johnraff · 2022-01-30 05:11:30

So it's not just a question of what Debian supports, but what the population of package developers care to provide.

Anyway, with BL's current staff level, I don't think providing both systemd and sysvinit versions is on.

For people wanting something close to BL on a non-default platform (and this means anything other than systemd, even if Debian support it) then my suggestion of a customized netinstall script still looks like a fairly easy way forward.

Bearded_Blunder · 2022-01-30 05:27:14

Indeed. Two versions would be silly, & the netinstall is entirely suited to a minor tweak or two.
It wouldn't actually need much tweaking at all.

I only really posted again on here because I'd run across some mention of apt's internal logic & remembered we'd both said we didn't really know how it handled things when it had multiple options.

johnraff · 2022-01-30 05:48:41

Bearded_Blunder wrote:

I only really posted again on here because I'd run across some mention of apt's internal logic & remembered we'd both said we didn't really know how it handled things when it had multiple options.

And thanks for that! Reading now...

...and learned that apt's algorithms are quite complicated, and not set in stone. Aversion to using tricky OR dependencies reinforced.

Last edited by johnraff (2022-01-30 06:41:40)

DeepDayze · 2022-01-30 23:37:10

hhh wrote:

@ B_Bl, we'd discuss it on the forum before doing anything. But quoting from your link...
Debian Wiki/Init wrote:
Since jessie, only systemd is fully supported; sysvinit is mostly supported, but Debian packages are not required to provide sysvinit start scripts. Support for init systems other than systemd is significantly improved in Bullseye. runit is also packaged, but has not received the same level of testing and support as the others, and is not currently supported as PID 1. As of Bullseye, a collection of sysvinit start scripts that have been removed from their original packages is provided in the orphan-sysvinit-scripts package.
So it sounds like sysvinit is making a comeback on Debian but isn't really there yet (orphaned scripts package, ouch).

Yes and maintaining those scripts will be a nightmare not to mention cleaning them up to work with newer system infrastructure. Will maintainers take back the scripts that pertain to their package(s)? That remains to be seen, but a nice idea to have kept them around in a separate package to hold them for the time being.

Bearded_Blunder · 2022-01-30 23:58:30

manyroads wrote:

Has anyone considered using:
1. MXLinux (built using Debian Stable offering systemd & sysvint) or
2. Devuan (Debian stable without systemd but offering SysV, OpenC, Runit) ?
3. antiX might also provide a good Debian base as might
4. Artix if you wanted a non systemd arch distro.
Seems like the above might offer approaches to numerous of the issues mentioned in this thread.
Just curious.... FWIW. I am hardly capable of addressing the numerous concerns discussed in this thread.

I personally considered & dismissed it, while some (a lot) of the Bunsen packages would be just fine on such systems some will arrive broken, with unknown consequences, which might involve system breakage. Until the check it was actually on real Debian was made more robust bunsen-welcome would have messed up apt's sources on Devuan for sure and possibly the others listed.

Now.. I can tell you about three methods of getting the metapackage more or less "installed" on Devuan at least, basically any of the same hacks that get it done on Debian, but I consider it unwise. Nor am I willing to invest the time in checking what works & what's broken & needs removing in systems that aren't actually Debian, so my advice is "Just don't do it".

Swiching init in Debian isn't that difficult if you do it on a command-line only install, even if I rambled a lot in my how-to. The only gotcha I've found is then getting the Bunsen metapackage on, owing to the hard depend listed for dbus-user-session, & some minor bitching (couple of lines per login) in .xsession-errors that "dbus-update-activation-environment" can't find "systemd -- user" & is consequently ignoring the "--systemd" argument, which seems pretty harmless when you install everything *except* dbus-user-session.

I've not tried MXLinux, however, I suspect if you'd got that installed using sysvinit, the depend on dbus-user-session would most likely switch you to systemd since it in turn has systemd as a depend, which it may or may not manage without breaking your install massively in the process. Again, I wouldn't advise trying.

I know about nothing regarding antiX.

If you're playing with Artix you'd probably be better off pulling things from Archlabs since that's arch based too.

Bearded_Blunder · 2022-01-31 00:54:43

DeepDayze wrote:

hhh wrote:
So it sounds like sysvinit is making a comeback on Debian but isn't really there yet (orphaned scripts package, ouch).
Yes and maintaining those scripts will be a nightmare not to mention cleaning them up to work with newer system infrastructure. Will maintainers take back the scripts that pertain to their package(s)? That remains to be seen, but a nice idea to have kept them around in a separate package to hold them for the time being.

"Debian Ecosystem Init Diversity Team" <debian-init-diversity@chiark.greenend.org.uk> are the current maintainers for orphan-init-scripts, I suspect given their title they have some motivation to actually do so.

#1 2022-01-18 03:02:36

Proposal to make bunsen-meta-all (and lite) init agnostic

#2 2022-01-19 06:26:59

Re: Proposal to make bunsen-meta-all (and lite) init agnostic

#3 2022-01-20 02:48:23

Re: Proposal to make bunsen-meta-all (and lite) init agnostic

#4 2022-01-20 15:13:16

Re: Proposal to make bunsen-meta-all (and lite) init agnostic

#5 2022-01-20 23:58:52

Re: Proposal to make bunsen-meta-all (and lite) init agnostic

#6 2022-01-21 08:28:23

Re: Proposal to make bunsen-meta-all (and lite) init agnostic

#7 2022-01-21 10:15:24

Re: Proposal to make bunsen-meta-all (and lite) init agnostic

#8 2022-01-22 01:24:02

Re: Proposal to make bunsen-meta-all (and lite) init agnostic

#9 2022-01-22 02:08:55

Re: Proposal to make bunsen-meta-all (and lite) init agnostic

#10 2022-01-22 07:25:43

Re: Proposal to make bunsen-meta-all (and lite) init agnostic

#11 2022-01-29 11:20:56

Re: Proposal to make bunsen-meta-all (and lite) init agnostic

#12 2022-01-29 14:36:03

Re: Proposal to make bunsen-meta-all (and lite) init agnostic

#13 2022-01-29 16:20:08

Re: Proposal to make bunsen-meta-all (and lite) init agnostic

#14 2022-01-30 01:14:55

Re: Proposal to make bunsen-meta-all (and lite) init agnostic

#15 2022-01-30 05:11:30

Re: Proposal to make bunsen-meta-all (and lite) init agnostic

#16 2022-01-30 05:27:14

Re: Proposal to make bunsen-meta-all (and lite) init agnostic

#17 2022-01-30 05:48:41

Re: Proposal to make bunsen-meta-all (and lite) init agnostic

#18 2022-01-30 23:37:10

Re: Proposal to make bunsen-meta-all (and lite) init agnostic

#19 2022-01-30 23:58:30

Re: Proposal to make bunsen-meta-all (and lite) init agnostic

#20 2022-01-31 00:54:43

Re: Proposal to make bunsen-meta-all (and lite) init agnostic

Board footer