there must be a matching Ubuntu version for any given Devuan distribution version, that has the crucial libraries should be in the same place, right? If so, a Launchpad PPA with custom packages based on the Devuan packaging metadata (the `debian` subdir) ought not be too risky?

Yes, the packaging is the same, so libraries all go to the same places in debian, devuan and ubuntu. But ubuntu is based on debian sid, not debian testing after freeze, so library versions might not correspond between comparable releases of ubuntu and either debian or devuan. YMMV.

Was it your intention to link to the generic Debian wiki landing page (on which I didn't see a DontBreakDebian section)?

Of course not.  I fixed it.

Use PPAs with Debian or Devuan at your own risk.  Please take DontBreakDebian to heart.

It always makes me chuckle when people suggest that any use of free software (esp. under the GPL) isn't entirely at your own risk... It's very easy on Ubuntu too to break something with an illconceived package from a PPA. In fact, using multiple package sources in a design that's already subject to dependency nightmares (split packages with individual, versioned dependencies) is already a recipe for disaster in itself. Been there, done that... (heck, I almost lost my entire install because I thought I could simply back out of experimenting with the official systemd package for Trusty, without using ZFS snapshots as a safety net).

Was it your intention to link to the generic Debian wiki landing page (on which I didn't see a DontBreakDebian section)?

Do Debian and/or Devuan have a similar site/service in place? Upgrading to just about any newer distro would presumably rob me of my preferred (minimalistic) KDE Plasma4 (sic, Four) DE so I'd be very tempted to get that up and running myself and evidently I'd prefer to be able to use an external build service for that.

EDIT: there must be a matching Ubuntu version for any given Devuan distribution version, that has the crucial libraries should be in the same place, right? If so, a Launchpad PPA with custom packages based on the Devuan packaging metadata (the `debian` subdir) ought not be too risky?

edit: corrected incomplete link

If I understand correctly, one shouldn't use Debian's repositories but one can use the repositories certain companies put online (Oracle for VirtualBox, Mozilla for Firefox and Thunderbird, LLVM for clang etc) and install packages from those repos (as long as they don't depend on packages only available from Debian or Ubuntu).

I'm currently using KUbuntu 14.04 with an increasing number of packages I backported myself from later versions or simply built locally and installed in a parallel prefix. Sooner or later I will have to upgrade and I'd rather not go the systemd route. The LaunchPad PPAs I maintain also contain other software that's not a backport (like Freetype/FontContfig/Cairo with the Infinality patches).
Do I understand correctly that I should in principle be able to continue to use these PPAs?

Thanks!

https://dev1galaxy.org/viewtopic.php?id=2762

edit: Nevermind, didn't realize there was a second page with the solution. Thanks
Just had to

apt install libelogind0=241.1-1

and done, no more held packages.

I've tried some commands but those 3 packages are simply being held and nothing seems to make them go away or upgrade them.

https://dev1galaxy.org/viewtopic.php?id=2762

~$ apt list --upgradable 
Listing... Done
elogind/testing 241.1-1 amd64 [upgradable from: 234.4-2]
libelogind0/testing 241.1-1 amd64 [upgradable from: 234.4-2]
libpam-elogind/testing 241.1-1 amd64 [upgradable from: 234.4-2]
# sudo apt upgrade 
Reading package lists... Done
Building dependency tree       
Reading state information... Done
Calculating upgrade... Done
The following packages have been kept back:
  elogind libelogind0 libpam-elogind
0 upgraded, 0 newly installed, 0 to remove and 3 not upgraded.

I've tried some commands but those 3 packages are simply being held and nothing seems to make them go away or upgrade them.

If you have a minimal Devuan install it can be copied to the target partition with rsync

We do have that:
https://files.roundr.devuan.org/devuan_ … imal-live/

HTH!

crankypuss wrote:

Exactly why can't a hibernated system be distributed as the install iso, you just have to be able to boot from the damn thing.

A hibernated system already knows what hardware you have, where it is and what modules need to be loaded. That saves a lot of time.

Yes, and unless the hardware has been changed it will be the same as it was when it was shut down, and if the hardware was changed, you can initialize the new hardware.  Unless things have changed in the world it takes much less time to identify the hardware than it does to initialize it.

If you have a minimal Devuan install it can be copied to the target partition with rsync (or dd, though rsync is faster in my experience) and assuming all the drivers are present it'll start right up like a champ.   Then you can install whatever you want.  The trick to that part seems to be that there's no really good/comprehensive customization facility; apt is great if you already know what you want to do, synaptic is easier but still needs some user understanding.

But then, what do I know

I had, for a time, a moderately spec'd desktop that could do a cold start in under 10 seconds, using an SSD, running Funtoo.

My Debian machine do a cold start in uder 10 sec. Same with Devuan Ascii. Of course I don't use any display managers, or DE. Only

startx 

and old good iceWM.

On the other question, you can always compile from source - most (if not all by definition) open source projects have access to source. You can get the source, and normally follow the bouncing ball.

Exactly why can't a hibernated system be distributed as the install iso, you just have to be able to boot from the damn thing.

A hibernated system already knows what hardware you have, where it is and what modules need to be loaded. That saves a lot of time.

Currently, you can use the installer isos to install directly from the medium to avoid having to download the packages. That can save you some time, but those packages still need to be unpacked and configured. Or you can use the live isos and avoid downloading, unpacking and configuring the packages, but then you don't get to choose what packages are installed.

If you want a package selection that's different from the default, then you either have to do it yourself starting from a minimal install, or you have to find a derivative distribution that has what you want.

I keep thinking of other ways to do this, but I haven't come up with anything that I think is good enough to replace what we already have.