pkgsrc-Users archive

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

Re: pkgin for sparc



Julien Savard <juliensavard17%gmail.com@localhost> writes:

> i started to use pkgin on my old sparcstation5. I use the default netbsd
> repo :
>
> ftp://ftp.netbsd.org/pub/pkgsrc/packages/NetBSD/sparc/7.0/All/

That is the best link for now, but it's packages from 2016Q3.

> Thing is, when I compare with, for instance sparc64 architecture, there is
> a lot less package :
>
> ftp://ftp.netbsd.org/pub/pkgsrc/packages/NetBSD/sparc64/7.0/All/
>
> It make 462 packages for sparc vs 16325 packages for sparc64. ( FYI amd64
> has 18143 packages ).

So that's pretty impressive for sparc64.

> Out of curiosity, it is the right place to ask why ?
> Why the huge gap between the number of package for this architecture ?

Yes.  Because except for i386/amd64 and perhaps arm, NetBSD package
builds are done on a volunteer basis by NetBSD developers with their own
hardware.  (As opposed to i386/amd64, where they are done by volunteers
on TNF hardware).  Many of us have sparcs (non64) in our basements but
not so many of us have them powered on right now.

(Not that you asked, but Joyent publish SmartOS/Illumos and Mac builds.
As far as I know their cloud does not have 32-bit sparcs ;-)

> And can I help ? I'm ready to help, even compiling myself the
> packages, but I might need some guidance here about how to "publish"
> packages to the NetBSD site.

We do not publish packages built by non-developers, as a security
guideline.  (That doesn't mean I or anyone else thinks you are a bad
person; we're just careful about things being done on behalf of the
project.)  Hoewver, we are happy to put a note pointing to your
packages.  As an example, see
  ftp://ftp.netbsd.org/pub/pkgsrc/packages/Darwin/SEE_ALSO

You can certainly build packages on one machine and use pkgin to install
on others, or bulk build on one machine and use pkgin on the same
machine.

Things you can do to help the cause of sparc package builds are:

  Set up a bulk build (presumably a subset, and then increase as you can
  cope), and once stable send reports to the pkgsrc-bulk@ list.
  Reasonable choices are latest stable (2017Q2 today) and HEAD.

  Set up distcc to speed up your builds.  If you use ssh because you're
  too paranoid to run distcc unencrypted, and you figure out a nice way
  to cause the right cross compiler to get run based on which machine
  you come from, or something, post about that here too.

  Publish your packages and announce them here.  Feel free to send me a
  SEE_ALSO file and I can place it on the ftp site.

  Fix build issues and submit the fixes.  Keep in mind that we fix
  things on HEAD and if warranted on the stable branch.  (My own
  philosophy is that a quarter goes by quickly so unless it's security
  or a fix that unblocks vast numbers of packgaes I tend not to request
  pullups.)  But, most fixes to stable will apply to HEAD


It's good that you are working on 7.  6 is getting crufty, and 8 is in
beta.  I think 7 is a good place to be fixing packages right now, and
argubaly choosing 7 is the standard approach.

Greg

Attachment: signature.asc
Description: PGP signature



Home | Main Index | Thread Index | Old Index