pkgsrc-Users archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: How to best submit fixes to pkgsrc
Hi Greg,
thanks for your answer. My comments below
On Thu, 30 Dec 2021 14:12:16 +0100,
Greg Troxel wrote:
>
> [1 <text/plain (quoted-printable)>]
>
> Carsten Strotmann <carsten%strotmann.de@localhost> writes:
>
> > I'm rebuilding my pkgsrc setup on Solaris 9, MacOS 10.4 and MacOS 10.9
> > during the last days and I found a couple of issues (and
> > workarounds/fixes).
>
> I'm unclear on Solaris versions but am guessing that pkgsrc Solaris
> people might consider 9 new enough to be acceptable for bug reports.
>
> On Mac, 10.4 and 10.9 are ancient, and I realize you know this :-) See
> bootstrap/README.macOS:
>
> Because Apple drops support for previous hardware faster than the
> hardware fails, many machines cannot be upgraded to recent versions of
> macOS, creating a greater than usual desire to support old systems.
>
>
> A side note is that some people run NetBSD on old Mac hardware. For
> example, I am currently using a MacBookPro from 2008 and a MacBook from
> 2006 as pkgsrc build machines. I'm not saying you *should* do this,
> just pointing out that it's a way to use old hardware without old
> software.
Yes, I'm aware of this and I run some older machines with NetBSD and
OpenBSD, and that is a fine solution.
But I also have some machines where I want to keep certain command
line tools "recent" (ssh, git, vim, python/ruby/lua, emacs(en), gcc, forth).
This is definatly "retrocomputing", I don't use these machines "in
production", but I sometimes do software development on these old
machines.
>
> > What is the best way to report these issues/workarounds/fixes to the
> > pkgsrc project?
>
> First, the question is whether the problem is in the upstream tarball
>
> * If when you unpack the upstream tarball and build it using their
> instructions it fails to build, fix the problem there and submit it
> to upstream. Then you can add patches to pkgsrc, making it
> effectively like upstream released a micro with those changes.
>
> * If upstream does build, but the package doesn't, then you've
> found a packaging bug. You can fix the package.
>
> Once you have package changes, there are basically four paths:
>
> * Submit a PR (send-pr on NetBSD, and presumably in pkgsrc).
>
> * Mail a patch that fixes the issue, along with a commit message, here.
>
> * Same, but figure out which pkgsrc developer takes care of the
> package by checking MAINTAINER or commit history.
>
> * Put a version of the package that works in pkgsrc-wip, which doesn't
> require meeting pkgsrc standards and where commit access is handed
> out pretty much just for asking:
> http://pkgsrc.org/wip/
> and then when the package in wip works, ping here or someone you
> think cares about the package.
>
> Comments:
>
> Bug reports without fixes for 10.4 and 10.9 don't belong in the bug
> tracker. Sorry, but nobody is going to pay attention and it's just
> clutter. Even with fixes, it's getting iffy. It's starting to feel
> like 10.13 is retrocomputing, even though there's hardware that's
> totally ok and beefy enough to be usable (e.g. 16G RAM, big SSD). The
> only 10.11 machine I know of is unusable due to having only 2G of
> RAM.
I will only post patches/fixes where the fix is straightforward and
does not create issues for modern platforms (modern machines should
always be the priority).
>
> Patches to accomodate old systems can be added if they are clean,
> meaning they don't cause significant additional cognitive load, or any
> negatives for users of maintained operating systems.
>
> If changes to pkgsrc result in adding a patch (to the upstream
> distfile), pkgsrc norms require that to have an explanatory comment
> and that the change be filed with upstream and a reference put in the
> patch file, or an explanation that there is no functioning upstream.
> While this (documented) norm is fairly rough in pkgsrc, I'm not
> inclined to bend from it when accomodating old systms.
>
ACK, will do that.
>
> Beyond that, you are welcome to ask for help in working on this. Do
> read the guide (doc/pkgsrc.txt) through all the way first. pkgsrc has a
> tradition of helping new people in the hopes that we can talk them into
> further contributions.
Thanks for your work on pkgsrc and helping out.
best wishes for a good new year 2022!
Carsten
Home |
Main Index |
Thread Index |
Old Index