Re: [Tails-dev] Debian security / porting support and embedd…

Delete this message

Reply to this message
Author: Neil Williams
Date:  
To: adrelanos
CC: tor-talk, tails-dev, debian-derivatives
Old-Topics: [Tails-dev] Debian bureaucracy [was: Tails Mac support [Was: Training Journalists in Istanbul]]
Subject: Re: [Tails-dev] Debian security / porting support and embedded codebases
On Mon, 25 Feb 2013 21:09:19 +0000
adrelanos <adrelanos@???> wrote:

> 1) Tor Browser
>
> It can't make it's way into Debian due to "no code duplication policy".


i.e. security support and porting ability.

Every time a codebase gets duplicated amongst a variety of packages,
there are inevitable problems:

0: bugs in one version take forever to get fixed in all versions

1: security fixes in the embedded code need to be applied across many
packages instead of one. As security support this may need to be done
quickly and is therefore best done in a single package not dozens.

2: porting packages embedding that code becomes more difficult
because, again, changes need to be pushed through all copies, each of
which have their own build systems / patch systems / compatibility
issues. You cannot generally just copy the one patch into each package,
each one has to fit into the rest of the packaging and be tested.

Embedding code within packages *makes more work for everyone*. It is a
*bad* thing to do.

It is not about disc space (although the space required for a complete
Debian archive across all architectures and suites is not an
inconsiderable factor). It is about duplicated workload.

> The answer for such cases is "merge your patches upstream" - yes, but if
> upstream isn't interested?


Then create a new upstream which can take the patches and package the
code *ONCE*.

> 2) The MATE Desktop
>
> They didn't make their way into Debian, also because of the "no code
> duplication policy".


Same reasons - there have been and will continue to be security bugs in
packages like cairo which underpin GNOME2. Duplicating code is not the
answer.

> There are other applications, which didn't make into Debian repository,
> because of that policy...


Good. Debian is better off without more embedded code copies and needs
to continue pushing against embedded code in existing packages.

> In conclusion...
>
> I think the correct question to ask isn't "does it duplicate code?", but
> "won't it break something?"


All duplicated / embedded code breaks everything else which embeds the
same code because all copies need to be fixed at once.

Every package which embeds code available in a separate package is
buggy by definition - it is broken by design.

>, "is it well maintained?"


By whom? Every time code is duplicated, you also duplicate the number
of people who need to do something to update that code.

> , "is upstream
> generally ready? (not too many bugs)".


Which upstream? Every upstream embedding the code will have their own
release schedules, timelines and priorities.

Single codebase, single upstream should be the objective.

--


Neil Williams
=============
http://www.linux.codehelp.co.uk/