:: Re: [Dng] No, the majority doesn't …
Top Page
Delete this message
Reply to this message
Author: T.J. Duchene
Date:  
To: Martinx - ジェームズ
CC: dng@lists.dyne.org
Subject: Re: [Dng] No, the majority doesn't knows. Long life to the Scientific Method!
> The reasoning is very simple. APT does not provide the mechanisms to
ensure >that things like systemd do not happen again.

Admittedly, I should have been clearer. The reason I think that APT should
eventually be forked is that:

a) Extremely important: It does not provide a clear rollback mechanism for
package files to previous versions of binary packages.
b) Related to user choice. It does not provide package methods for
multiple versions of init or other system utilities that might exist.
c) It does not provide for multiple versions of binary files to be
installed on a system in a coherent manner, say two versions of Perl.
d) Less important but still a consideration is that it does not provide a
method for delta files.


And that is just the most obvious thoughts. I could probably come up with
a handful more given time. I would expect that if we succeeded in adding
these and other features that Debian might merge them back into APT, should
their egos allow it.

I'm not going to crusade and argue for why APT really needs change. That's
for some other time. I'm just saying that I've seen better resolution
heuristics and feature sets elsewhere.

Personally, I think APT should undergo a process of gradual replacement,
and before anyone comments that that would mean a complete break with
Debian, I would humbly disagree. Debian has conversion tools for RPM to
DEB, for example. There is no reason that if we did decide to break away
from Debian, that we would have to completely jump ship.

Frankly, it is my opinion that even if Devuan takes off, in about 2
releases or about 5-6 years, keeping regular package compatibility with
Debian will be impossible anyway. If Debian stays on the systemd path,
Devuan will have to completely rebuild and repackage every single piece of
software that even touches startup. Contrary to what people keep saying,
there are subtle but distinct scripting differences between System 5 and
Systemd.

Systemd is NOT a drop in replacement, nor does it allow for 100%
compatibility with System 5 startup scripting.