Re: patches question

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

On 2016-06-23(01:09:43PM+0200), Andreas Enge wrote:
> Hello,
>
> On Thu, Jun 23, 2016 at 10:41:08AM +0000, ng0 wrote:
> > After the last reply to my netcat-openbsd, I am
> > uncertain about the kind of patches which can
> > be included by policy.
>
> my opinion is: as few patches as possible, given that we need to maintain
> them with very little peoplepower, and that we do not intend to substitute
> ourselves to upstream. Also, if possible, things should be reported upstream
> so that we can take patches out again. Another reason to do so is that
> packages should essentially behave in the same way as the same software
> compiled by hand. Recall also cases of security problems introduced into
> other distributions by non-upstream adding patches to cryto software they
> did not completely understand.
>
> > For firefox, I would start to include what fixes
> > buildprocess for us and fixes bugs (including
> > features) upstream has not bothered to close yet
> > or in general.
>
> Particularities of our build process may clearly make patches necessary
> (although I often prefer to treat them more generically in a build phase,
> using "substitute*", for instance, which may be more robust across package
> updates). After that, I would consider mainly security fixes and maybe
> important functional fixes made by upstream that are not yet in a release.
> Clearly features that upstream does not bother to implement are not acceptable
> for patches, as they will have to be maintained and adapted indefinitely.

Okay, sounds logical and reasonable.
I wanted to ask Debian about the netcat-openbsd case
and why certain features are added/fixed.

> > For firefox, bundled libraries and applications
> > can be patched away (system graphite+harfbuzz),
>
> Unbundling and removal of non-free parts are also possible cases, although
> most of the time this is done by a call to "delete-file-recursively" in a
> snippet.

The length of the package definition in this case could
be smaller. With comments it's at 300 lines now.
Some temporary patches to open bugs would increase this
length.
That's my only motivation for the patches directory,
length of code. If it does not matter, I will do it
in the packages themselves as long as possible even
for non-trivial fixes.

> > That is what the netcat-openbsd-* files of debian
> > are about I assume (but I have not asked debian
> > yet).
>
> I do not know about this particular software, but while Debian is a good
> source for copyright info and patch material, they definitely are not our
> lead as to the decision of whether to include patches: If you divide our
> number of packages by the number of regular contributors, you will end up
> with a few hundred packages per person. I think Debian has no particular
> policy as to which patches are acceptable, and that this is mainly up to
> the package maintainer. In our case, since we do not have designated
> maintainers, every additional patch is an additional burden on the person
> trying to update or more generally work on a package later. As a bad example
> of a Debian patch, I have encountered one that corrected an English typo
> in a comment (!) in the C code of a package.
>
> Andreas
>
>

In the case of netcat-openbsd, Debian is the Linux upstream,
maintaining the port of netcat from OpenBSD.
The patches have not seen an update since 2012 and are still
functional.
I can understand that we don't want to maintain more patches
than necessary, so in the case of netcat-openbsd I'll contact
Debian, as mentioned in the thread of the patch, to ask about
a merge of their patches into their maintained port.
If the reply is negative, I'll look at the patches and only
take what's really necessary.

--
♥Ⓐ ng0
For non-prism friendly talk find me on
psyced.org / loupsycedyglgamf.onion