Hi Walber,
On Mon, Apr 26, 2010 at 01:53:40PM -0400, Walber Zaldivar Herrera wrote:
Hi
I'm working on SiXdeb a project from a group of cuban folks to
generate Cuba oriented Debian Blends or CDDs. We have a doubt: could
be considered a *Debian Blend* a CDD with packages from diferent repos?
For example: A lenny CDD with OpenOffice from debian-backports repo
and multimedia codecs from debian-multimedia repo
Good question!
Short version: No - mixing across branches is unpure!
Slightly longer: I would say "no", but I suspect that Andreas Tille or
others might disagree. :-)
One of the fundamental aims I see with the Blends is that of being able
to fully state that "it IS Debian".
Debian do not officially ship a distribution mixing in packages from
backports.org or debian-volatile.
One test is "would I risk upsetting a DD if filing a bugreport on this?"
Some Debian developers only want to deal with bugs in "their" packages,
not any derivatives of them, and only when used in its intended
environment: As part of Unstable as of same date or later, or as part of
a later Testing or Stable, when the package eventually reached there.
PD: Sorry for my English, it isn't so good as I wich
Don't worry, your english is fine! No problem understanding you :-)
When I coined the term "Debian Pure Blend", it was intended as a
user-friendly marketing term, with the more exact techincal term being
the abbreviation DDD, meaning "Debian-packaged, Debian-composed, and
Debian-released". With that I meant to make it indisputable that not
only should both source and binary packages be the ones accepted into
Debian, but also the relationship - i.e. the year long process of
deciding which packages works reliably together, and the way the
packages are installed (currently on CD or DVD), should be the Debian ways.
One thing I wanted to avoid was packages grabbed from Testing rebranded
as any breed of "Stable Debian".
Another thing I wanted to avoid was installing "sleeping agents" in
Debian approved packages, which was triggered only when installed
through custom install methods"[1]
- Jonas
[1] Debian-Edu currently use this approach to do things that violates
Debian Policy: The violations are impossible to do using official Debian
install methods so Debian Release Managers have decided to lower
severity of bugreports against it, but I fear the day a Debian-Edu user
files a bugreport against a Debian package stating that they use a pure
Debian system, when in reality they used an unpure install method
triggering unusual (and potentially fatal in corner cases) behaviour.