Rick Moen <rick@???> wrote:

> For completeness, I'll mention that, if a Debian 8 'Jessie' or Debian 9
> 'Stretch' system does end up suffering packager-caused intrusion of
> systemd into important packages (for some value of 'important' ;-> ),
> then I can confidently predict that alternative packages in third-party
> repos will become wildly popular among Debian admins.

I try to stay out of discussions like this, but I will comment on just this point.

For myself, and the servers I run*, the intrusion has already happened - a gratuitous dependency from one of the ClamAV packages on libsystemd0 in Debian Jessie.
You can argue, and many have (especially the ClamAV package maintainers in "very firmly" rejecting a bug report) that libsystemd0 is not systemd. Well maybe, but ...
It is "part" of systemd, and I assume systemd won't work without it. It may be benign now (the "all it does is returns that systemd isn't running" argument), but given the way things have been going, I have precisely zero trust that "stuff" won't find it's way in there in such a manner that having it means having bits of systemd running. That wedge is in there, they can just keep tapping it in over time.
No way am I having a trojan like that running on my servers.
But so many packages have what should really be a "soft" dependency on it. Surely it can't be "really hard" to have a system that allows you to use something if it's there, and not if it isn't ? Downloading the package source, and building a local systemd-free version is beyond my skill set - not to mention the ongoing maintenance every time the package is updated. This maintenance is alluded to in earlier threads.
Globally, it's far more efficient if one person does that work, once, and others get to share it


And I have zero confidence in the ability of the programmers on the project. Partly based on what I read of the way bugs are treated in systemd, and partly on what I read about Lennart Poettering's previous projects, and partly on what I can see for myself ...
Now, I'm not a programmer (I've done stuff in the past Assembly, PLM, Pascal), but these days I'm limited to a bit of Bash hacking), but as an admin I know what the sync call is there for, and what it's supposed to do. I find it strange then that they should go to long lengths to create the oxymoron of an async sync https://github.com/systemd/systemd/blob/master/src/basic/async.c
The comment says it all really : "
> It kinda sucks that we have to resort to threads to implement an asynchronous sync(), but well, such is life.

I've seen in the past what an async sync can do for data. Apple got seriously hit some years ago by a disk drive manufacturer that played this game. On shutdown, the OS flushed all data and waited for the drive to respond that the data was written before turning the power off. Only the drive manufacturer "had a great idea" and the drive still had dirty data in it's own cache when the power went off - sometimes, depending on amount of data, and timing, etc. I think you can see where that leads !

So we seem to have a project that will allow someone to write an oxymoron of a function, and allow it into the codebase. I note the file says "Copyright 2013 Lennart Poettering"



But on the subject of alternative repos, well that's a whole debate in itself.
For many of us, if something goes wrong and the brown stuff is flying off the fan in all directions, one of the questions people will ask is "where did stuff come from".
At present, my answer to that is : from the official Debian repositories except for X, Y, and Z which came from vendors repositories (eg, I have Ubiquiti's Unifi WiFi management system running on some systems). For most PHBs, that's an acceptable answer.

For many people, if you have to tell the PHB that some of your packages came from "some random site on the internet" then that causes some political issues internally. However, what Devuan are doing is keeping all those Debian packages that don't need fixing (yet) and publishing a repo of fixed packages for those that do.
The difference though is that the unified whole is something some of us can point our PHBs to as a "supported distribution" - it's not (as far as the PHB is concerned) Debian with a few outside hacks, it's the distribution Devuan.

Personally, I'd not have a problem with adding a Devuanish repo over and above the Debian repos and perhaps adding a little pinning foo - but many admins don't have this luxury with their employers hat on.


* I think we have a fair bit in common - everything I use for work is headless, the only "desktop" Linux I use is for my MythTV frontends at home.


PS - I've read the essay on forks. I vaguely recall having read it before, and it makes good reading.
I would hope that in time, "Debian" will come to realise it's made a mistake and the forks can re-converge and merge as you describe for some scenarios. If not, then we'll see whether Debian's or Devuan's approach is more popular long term !


Wow, that ended up a lot longer than I planned :-(