Re: No native packages?
Ian Jackson <email@example.com> writes:
> Gergely Nagy writes ("Re: No native packages?"):
>> There are two native packages I maintain, and I've yet to hear a good
>> reason for making either of them non-native. Making it harder and much
>> much more inconvenient for downstream distributions to modify them is a
>> *goal* in these cases: to make it harder to diverge from one
> I haven't looked up to see what these packages are, but I worry that
> what you are doing here is undermining the freedom of our downstreams.
The two packages in question are dpatch and dh-exec, and yes, what I do
with them could be considered as undermining the freedom of
downstreams. However, in this two cases, I believe that is a good thing,
as in the long run, neither we nor downstream should want to deviate
from one an other.
Why? Because if downstream introduces something there, and start to rely
on it, while upstream the same thing does not get introduced, or does in
a different way, everything that builds on either, will fall apart, and
make it that much harder to work together.
> The ability of our users and downstreams to choose to modify the
> software we distribute is the core of their software freedom. As a
> project we should be making it easier, not harder, to produce modified
I agree, but to a limit. But there are tools that should be patched as
little as possible, to preserve interoperability between distributions,
and both dpatch and dh-exec are such tools that when they diverge in
either down- or upstream, interoperability suffers. Want something
included? Get it in upstream first, so things won't break.
That is one of the reasons I kept both as native, and why I believe
there is no compelling reason to change that.