Re: netcat-openbsd implementations

[ng0 <ng0@we.make.ritual.n0.is>]

Aron Xu writes:

> Hi,
>
> See comment below,
>
> On Wed, Jun 29, 2016 at 8:13 PM, <ng0@we.make.ritual.n0.is> wrote:
>>
>> Hi,
>>
>> I've seen you as the last person commiting to netcat-openbsd
>> for Debian in 2012[2].
>>
>> I have written a package definition for netcat-openbsd for Guix.
>>
>> At Guix we don't want to maintain forks through in-tree patchsets
>> and avoid it whenever possible. Patches are usually for fixing
>> CVEs and fixing severe build problems specific to guix.
>>
>> Now this is a problem which is reflected in the thread at [0]
>> (discussing the netcat-openbsd package).
>>
>> Resulting from the discussion I have questions for you:
>>
>> 1. I'd like to know if Debian could merge the specific changes
>>    applied to the OpenBSD package, available in the patches set,
>>    into the OpenBSD GNU-linux port.
>>    If this is not possible, could you give us the reason for it?
>>    My impression is that at least Gentoo, Gentoo deriviates and
>>    based systems, Archlinux, and Debian use the orig-source +
>>    the patches tarball.
>>
>
> This is long overdue - my intention was to keep netcat-openbsd to
> track the development of the openbsd one, but it appears not happened
> that way.
>
>> 2. Did you try to merge more generic changes back to OpenBSD?
>>
>>    From what I've seen so far, those are bug fixes and a minority
>>    of feature fixes.
>>
>
> Some of them was sent, but getting few responses.
>
>> 3. There's an initial statement in the README but as many of those
>>    are non-trivial patches, could you try and give an explanation
>>    on why they are needed,
>>    if they can't get merged into the Debian orig-source?
>>
>
> I don't treat this netcat-openbsd a full fork even if it's targeting
> an older revision at the moment. Also, maintaining patches are very
> easy using the git-buildpackage[1] tools for Debian packages.
>
> [1]https://wiki.debian.org/PackagingWithGit
>
>>
>> Third option I thought of, could Debian provide a tarball of
>> the orig-source with the patches applied, so there's no need
>> to conflict with systems currently pulling one or both of the
>> currently existing tarball.
>>
>
> I think it is hardly possible to provide another tarball because
> there's no way of doing that with current Debian infrastructure. But
> you can apply those patches easily using quilt[2]. In Debian, patches
> are applied automatically when extracting the source package using
> dpkg-source.
>
> [2]https://wiki.debian.org/UsingQuilt
>
>> We can apply all the patches in a way mentioned here [1], but
>> because we collectively maintain all the packages/source instead
>> of `n' specific packages per `n' specific developer(s) it would
>> be good in case Debian can't merge the changes to be able to
>> point to a reason.
>> For this, I ask for your permission to quote parts you give me
>> permission to use for, should for any reason this email
>> discussion not end up completely CC'ed on guix-devel.
>>
>
> No problem.
>
>> [0]: https://lists.gnu.org/archive/html/guix-devel/2016-06/msg00843.html
>> [1]: https://lists.gnu.org/archive/html/guix-devel/2016-06/msg00909.html
>> [2]: http://anonscm.debian.org/cgit/collab-maint/netcat-openbsd.git/commit/debian?id=db2b1d9a8d4644ef892f47d84606ee96598d23fb
>>
>>
>> thanks,
>> --
>
> Best,
> Aron

Thanks for your reply, Aron.

It's not very satisfying to read about the reactions of OpenBSD.

So what do others make of this?
Ludovic, any follow-up thoughts or actions regarding our thread
on this?
In my opinion we could apply the patches like you suggested, in
the source and not as in-tree patches.
-- 
♥Ⓐ  ng0
For non-prism friendly talk find me on http://www.psyced.org
SecuShare – http://secushare.org