Hello,
I'm one of the VUAs that originally starts the Devuan fork.

I have nothing to add to what Jude already sayd, he has already answered in a perfect way to all your questions.

I'll add just 2 cents...

Yes, Debian IS the right place for such patches. And sending patches to Debian and help from the "inside" was our hope. Sadly the results of the famous votation AND a lot of patches refused as "WONTFIX", "NOTABUG" and a lot of trolling calling who don't like systemd "incompetent", "troll" and in many other (even worst) manner doesn't help to make people wanting to send patches, and our only way to have what we need was to fork.

This is what we have tryed to do for months, before to fork.

This is a political, not technical, claim.
And it's to be intended as "we continue with the tradition, debian is changing, as we don't accept the change as we consider it a change for the worst, we try to continue a real debian for what real debian mean for us".

If we will come to be a downstream or a divergent distro it's up to debian actually, if they will make impossible to us to retain what we need/want and they will not accept our patches, we will probably diverge, if they will start accepting our code and maybe relax the barriers, we can come a side project, even inside, for debian in future, who knows.

4 members found this post helpful.

Actually, we are solving the problem using our constitution. While the document is still a work in progress (feedback such as your replies in this thread is helpful), the spirit of sections 2.1, 2.2, and 9.10 is to prioritize the inclusion of software that respects the user's freedom to run whatever sets of programs they want for whatever purposes. This includes packaging software so that it's easy to replace with alternatives without affecting unrelated aspects of the system. By making this prioritization our policy a priori, we avoid the situation entirely that I described earlier in Debian--if someone wants to include a package in Devuan, they are required to do so in a way that adheres to these provisions.

I have no doubt that Debian will ensure that its default init system works as flawlessly as possible out-of-the-box, so your experience with Jesse is unsurprising .

To get to your point about init, I should first clarify that OpenRC isn't an init system--it's a process management system. It gets started by whatever program lives in /sbin/init. Same goes for the s6 process supervisor suite, for example. This is a good thing in my eyes, since this gives me the freedom to choose my init separately from my process management.

A better example of a program that must run as PID 1 that Debian packages already would be runit. It's been in Debian since 2004, but without controversy, since it's packaged such that it doesn't need to replace sysvinit and it isn't tied to any unrelated (i.e. desktop) software.

Runit is a good example of the kind of packaging policy we're aiming for. Even though it must run as PID 1, the people who want to install, use, and/or replace it can do so without breaking anything. This is what we would require from the people who would want to package systemd from Devuan.

Granted, it may be a while before we include systemd, since systemd's design and GNOME's and KDE's new-found dependency to logind don't make this straightforward, but my point is that we are not fundamentally opposed to systemd as you and others seem to think. What we are opposed to are policies (and to a lesser extent, design decisions) that limit or take away a user's freedom to run programs as they see fit--either directly such as through long package dependency chains, or indirectly such as by prioritizing software that couples together unrelated concerns.

One of the problems of building for a fork also is the lack of if/else switches in original buildscripts that look for and enable/disable certain build flags during configuration stages. Obviously, few things are done to implement this, but it could be useful in cases like Devuan that wish to maintain openness with packages rather than being locked in and forcing package maintainers for the fork to rewrite every buildscripts.

To to say it, but if things like this make the case of do you (a) distribute your own reworked binary packages, (b) use buildscripts and from source packages like Gentoo/CRUX, or (c) try to work with the parent fork to have universal packages?

Dare I say SalixOS as an example is a fork of Slackware but maintains compatibility with Slackware. This helps Slackware and SalixOS both. Dlackware has a few variant packages rebuilt for systemd, but for the most part Dlackware and Slackware can co-exist to a point.

edit: nevermind ...

Fair enough.
Do note how this makes your "fork" non-technical as well (Ubuntu and friends all had a technical goal).

IMHO this is exactly why you will fail.
We don't do politics, our issues will eventually hit you as well.
Claiming you can remake/build Debian's entire infrastructure sounds wrong.

Ps: I'd still like to know what devuan did with its donations ...

Nevertheless, I do wish you all the best (though I do hope you will reconsider working "outside" Debian).

Politics and technicalities aside it is an independent fork. Devuan is Debian based, but is not Debian.

I thought Devuan is supposed to provide packages to eliminate the use of systemd, sort of like how deb-multimedia has replacement packages for existing Debian packages, and isn't a fork.

It doesn't eliminate systemd. It allows package independence to allow packages to be built without lock in dependence solely on systemd.

Devuan can be made with systemd, but packages do not have to be specific to systemd.

Believe me, replacing systemd components with less-encumbered alternatives and removing package dependencies are technically-involved tasks. Very much so.

As you can see, reports of our project's death are greatly exaggerated .

Could have fooled me. I wonder why DDs bother with a constitution, committees, elections, and GRs then.

Perhaps, but by the time they hit us (if they hit us at all) we will at least have had the benefit of seeing them coming. It's mutually beneficial, too--any issues we have to deal with before Debian will give Debian the same advance warning.

And yet we're doing it . In fact, we're taking the opportunity to make improvements in the workflow.

Latest financial statement (as of late April): http://www.devuan.org/devuan_financial_report_2015.pdf

Thanks! Don't worry about "inside" vs "outside", though--our code is open, so Debian can get our code no matter what our official involvement .

1 members found this post helpful.

A political claim doesn't make a whole project political only. Devuan isn't a political fork, it's a tecnical fork based ALSO on political views.

Every single word we all (even you) say is political when not strictly technical.

Well, you right. We have ALREADY rebuilt the core infrastructure.

We publish reports on how we exactly spend money coming from donations. Actually just few euros to buy a laptop needed for a non VUA contributor that wasn't having personal resources nor a decent machine for what he is coding. The rest is "when we will need that, we will be ready". Actually we are self-providing needed hw for free.

We have been forced to work outside debian, sadly.

1 members found this post helpful.

We are NOT like deb-multimedia. We provide a complete and indipendent ( and partially incompatible ) repository, deb-multimedia provide an add-on repo on top of debian one, and starting from devuan ascii ( our "testing", or 2.0 ) we will probably diverge from debian too if, from our point of view, debian will not fix the issues it actually has.

1 members found this post helpful.

So Devuan will be incompatible with Debian like Ubuntu?

Not like Ubuntu, more than deb-multimedia.

For jessie (both Devuan and Debian) we guarantee the compatibility needed for switch from debian to devuan by just changing the repository in sources.list and do an apt-get update && apt-get dist-upgrade.

For ascii and ceres, our testing and unstable, we will try to maintain the same compatibility level, but it isn't guaranteed and we can diverge from debian in potentially incompatible way in future.

Starting from jessie, we suggest to avoid repository mixing, if you put the devuan one you will have to remove the debian one from your sources.lists. Many ( the majority ) of packages are exactly the same, but some core components can have issues in different dependencies and/or conflicts if you mix them.

Anyway, a large set of packages remain identical, and pratically any external and unofficial debian repo like deb-multimedia should work in devuan exactly as good as it does in debian, at the actual state for all suites.

Although I do not care what happens to Debian, since I no longer use Debian or any Linux system, it is nice to finally see a couple of people involved with the Devuan project joining discussions. One of the concerns I had, along with at least a few other people, was the mysterious nature of the project, due to lack of visibility of the people involved. It is good to see members of the team engaging the community and clarifying a few things.

1 members found this post helpful.

WHEN ... When ... when ...

BLA ... Bla ... bla ...