Re: Rules for packaging forked software
On Sat, Feb 8, 2014 at 1:01 AM, Tomasz Buchert wrote:
> tl;dr => What is the Debian Policy about packaging forked software?
Forks are similar to embedded code copies; they mean more work for
various teams in Debian other than the package maintainer (especially
the security team). In general I think we should work with the
relevant upstreams to merge their forks together, which is in line
with the Social Contract. In some cases the fork is basically the
replacement for the thing that got forked (think Xorg, Inkscape,
LibreOffice etc) and we should replace one with the other in Debian
but those cases are rarer.
https://www.debian.org/social_contract
https://wiki.debian.org/EmbeddedCodeCopies
> Recently, libx86emu [1] entered Debian as a prerequisite for the
> newest version of hwinfo. Libx86emu and friends exists in at least 3
> different forms in Debian (see [2] for explanation) which are forked
> from a one single project. Now, I recently heard about viewnior
> which was ITP and RFP some time ago [3] and did not enter Debian
> because it contains a fork of libgtkview [4]. I encountered these
> two cases *myself*, what makes me think that it may be even a quite
> popular problem.
For the former case that is a genuine case of forked projects but I
couldn't find any reason for the fork. Probably the right solution
there is to get the relevant people from the three upstreams (Xorg,
libx86, libx86emu) working together to unify the code-bases or at
least reimplement the relevant features/fixes from one code-base in
the other so that all reverse deps can switch to the one code-base.
For gtkimageview I'm not familiar with the situation but I expect that
is more like the typical embedded code copies situation; viewnior
upstream probably didn't bother sending their few patches to
gtkimageview upstream. The right thing to do in that case is to get
the two upstreams talking about the patches so they can be included.
--
bye,
pabs
http://wiki.debian.org/PaulWise
Reply to: