guix-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: netcat-openbsd implementations


From: Aron Xu
Subject: Re: netcat-openbsd implementations
Date: Sun, 3 Jul 2016 17:52:23 +0800

Hi,

See comment below,

On Wed, Jun 29, 2016 at 8:13 PM, <address@hidden> 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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]