Matthew: Is the DCC a fork? Not by the standard definition of the term:
[A] fork is what occurs when two (or more) versions of a software package’s source code are being developed in parallel which once shared a common code base, and these multiple versions of the source code have irreconcilable differences between them.
Perhaps you use a different definition, so I’ll outline the differences between Debian and the DCC, and you (and others) can decide for yourself:
- Back of the envelope, the DCC contains 234 packages, of which 205 (87.6%) are taken from Debian sarge unmodified (as of DCC 3.0 PR1).
- Of the remaining 29 packages, 4 are the LSB 3.0 compatibility environment, which adds LSB 3.0 compliance in such a way that the sarge glibc and pam packages don’t need to be modified (the sarge versions aren’t LSB 3.0 compliant—see Jeff Licquia’s weblog for details here and here). Note that the only applications that use the LSB compatibility environment are LSB applications—the default application environment is the standard Debian environment.
- Of the remaining 25 packages, 19 are a backport of X.org from etch (again, as of DCC 3.0 PR1—there will be additional X.org packages in PR2). The DCC X.org environment is fully compatible with the standard Debian XFree86 environment—in other words, packages built on DCC-based distros will install and run on standard Debian sarge unless they use X.org-specific features (in which case they will link to one of the new X.org packages, such as libxcomposite1 or libxdamage1, not shipped in the DCC itself).
- The remaining 6 packages are backports of the LSB 3.0 packages from etch (lsb, lsb-base, lsb-core, lsb-cxx, lsb-graphics, and lsb-release), modified to 1. not manage the LSB dynamic linker symlinks (these are managed by the DCC LSB compatibility environment); and 2. add LSB_VERSION=3.0 to /etc/lsb-release, since DCC 3.0 is LSB 3.0 compliant.
-
The kernel is Linux 2.6.12.5 from etch built using the standard Debian kernel build tools and with the following additional patches applied: acpi, bootsplash, ppp_mppe, sk98lin, and win4lin.
The following kernel images are provided: 586tsc (standard x86), p4-smp (Pentium 4 with SMP support), k7-smp (Athlon with SMP support), mckinley-smp (Itanium II with SMP support), and amd64-generic (AMD64 and EM64T).
That’s it. Does that constitute a fork? Given that nearly 90% is bit-identical with sarge and the vast majority of the remainder are very lightly modified backports from etch, I wouldn’t call it a fork, but that’s just me.
Furthermore, there’s no parallel development going on, just integration work, and the differences that do exist are very minor and certainly aren’t irreconcilable.
By the way, as I’ve said before, I have no problems with forking, as long as it’s done with compatibility in mind, something the DCC is clearly doing:
My suggestions are a simple way to mitigate the inevitable compatibility problems of a fork without taking away the freedom to fork (which has never been a problem from my point of view, by the way—unlike most people in the free software world, I don’t spend a lot of time wringing my hands over the forking issue—it is, after all, one of the fundamental freedoms of free software).
Back to work. Again.
The win4lin patch is just adding hooks for a propritary module. I’m very disappointed that you’re adding such a patch violating my and many others
copyrights. I’ll reserve myself future legal actions.
DCC will start as a fork, but since it does not want to diverge it will live on for a while as a “branch to be merged” and hopefully, after all differences are solved, end up as a subset.
Ian, thanks for putting up with all the bullshit and smears you have to put up with from certain parts of today’s Debian crowd when trying to pull off anything useful or interesting. Keep up the good work.
> Does that constitute a fork?
How does that *not* constitute a fork?
Xorg 6.7 was >90% identical to XFree86 4.4. not a fork?
you seem to be hinging this whole notion of fork-or-not on the existance of irreconcilable differences between the developers of the branches. if it were my debian kernel, i wouldn’t accept the win4lin patch; it might be free software in the narrow sense, but it exists solely to make closed software possible.
sounds like fork material to me.
the delta between the DDCA code and stock Debian will continue to be non-zero, as the patches that the DCCA decides are necessary take time to make their way back into Debian. surprise, it’s a fork. claiming that some percentage of packages or some number of lines of code constitutes a Real Fork and that DCCA is therefore not a Real Fork is disingenuous. these are not the droids we’re looking for, apparently.
there’s no shame in forking. just don’t lie.
¿Why don’t use the gnome 2.10.2 from Debian testing? Works fine on my Sarge and bring some new and amacing programs like evince.
With gnome 2.12 in all the others distributions, the use of 2.10.2 at least dont look so old like the use of 2.8
I think than Progeny will be the “Debian for Workstation”
PD: Excuse my poor english… Im from Spain
I think you’ve made a mistake trying to modify the meaning of fork to the only people that have any interest in the topic. The “branch that merges back into the tree” is most appropriate here.
The DCC is absolutely the right thing to do, and some people won’t like the changes as a result and there’s nothing to be done about that.
Balancing the commercial interests and the totally free Debian interests will always be a gigantic challenge. Please exercise extraordinary care, because mistakes like your “fork” comments now harm both projects.
Good luck.
Just pointing here my aproval to dcc alliance. As company member, i like the idea of having a core that is common to several distributions and that is supported by some hardware and software vendors.
Regarding all debian criticism, i think that dcc can be a fork, by using the base and changing it, but not considering a fork because of dcc alliance’s objectives that are updating debian stable releases to business base.
For example, a fork is ubuntu, because it is 100% new and non debian compliant, the opposite of dcc. I am testing PR2 right now, only there are few mirrors … as someone said before, keep up the good work, and hopefully, with my help. Best regards