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



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.

> 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.
  
  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.


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.

Greg

Attachment: signature.asc
Description: PGP signature



Home | Main Index | Thread Index | Old Index