On Sun, Aug 16, 2015 at 12:13:04PM -0500, T.J. Duchene wrote:
> Well, I suppose the topic has been beat up enough, but I just wanted to clear
> up something before moving on. I want you to understand why I came to the
> Devuan list in the first place. I came here under the assumption that Devuan
> was going to be a "better Debian" without the shove the Technical Committee
> and the failure of the GR gave to one single point of view.

Well, we are here also to try to build up a "better debian" without
single point of view, yes, and to avoid "single point of view" for the
future, we are trying to move from "TC imposed view" to "VUA imposed
policy".

What's the difference?

With a TC imposed view like in debian, you can't assume any decision
before the decision is made. With a "VUA imposed policy", when the
policy will be complete and public, it isn't yet, you can know how
anything will be managed in future.

Basically, more power to our constitution and less to "people in
charge", where "people in charge" will just act as constitution
custodes.


> As far as I can tell, Devuan is about the same, with one difference. Devuan is
> willing to package systemd if it can be done cleanly - but nobody wants to.
> Debian will support System 5, again until nobody wants to.

No, it isn't like this.
It's this way:

Debian will support sysv, until nobody wants to.
Devuan will support anything that is feasible to do without ruining all
other options and impose one single way to do that, assuming someone
will accept to do the work.

The Devuan way is a policy, not something against a specific software.
Sadly systemd apply for this limitation as it can't be done without
hijacking whole system and imposing one way, so, it can't be an option
in my opinion. If anyone will get the work done and make it usable
without hijacking whole base system, well, Devuan will embrace it as an
option like anything else. Pratically, to me, this seems to be
impossible.

> Nexttime: "Devuan will not work to support systemd and will not work against
> it. We will not do any effort to support it, if someone want to work to package
> it in a way where it works WITHOUT needs support for any other package
> depending on it, we will consider to add it as an option, but we will NOT
> accept it if it ask us to put it in dependency tree. "
>
> That is all I EVER suggested, with one slight difference. That if it is
> somehow possible in the future to maintain two versions of the same package
> that the default version would be without systemd, but the other would be
> available at the users' option as a matter of choice.

This is of course feasible, yes. BUT how many packages will need two
versions? For systemd, too many, this is a way we can use for few
packages, but using it for 10000 packages is probably a too huge effort,
at least for the moment. In future, who knows.

NOTE: my nickname is "nextime", with 1 single t. Is isn't derived from "next-time", 
      it comes from the software called "nextime" that was in some wat
      the grandfather of the now called "quicktime" when it was born on
      NextOS.

--

Franco (nextime) Lanza
Lonate Pozzolo (VA) - Italy
SIP://casa@???
web: http://www.nexlab.net

NO TCPA: http://www.no1984.org
you can download my public key at:
http://danex.nexlab.it/nextime.asc || Key Servers
Key ID = D6132D50
Key fingerprint = 66ED 5211 9D59 DA53 1DF7 4189 DFED F580 D613 2D50
-----------------------------------
echo 16i[q]sa[ln0=aln100%Pln100/snlbx]sbA0D212153574F444E49572045535520454D20454B414D204F54204847554F4E452059415020544F4E4E4143205345544147204C4C4942snlbxq | dc
-----------------------------------