pkgsrc-Users archive

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

Re: Am i using it wrong?

Connor McLaughlan <> writes:

> I first tried to run debian as a base and to replace their non-working
> software packages with pkgsrc ones. This worked very well and most
> software would compile and run.
> This teached me the need for bootstrapping.
> But after a while i figured that some packages would only compile on
> NetBSD. So I switched the base system to NetBSD to get broader
> software possibilities.
> There are websites and tutorials that tell to bootstrap also on
> NetBSD,  so I kept it that way:

Interesting but as I see it the standard approach on NetBSD is to just
use pkgsrc.  It basically comes with the things you need in base,
configure for /usr/pkg.

However, it is unlikely that this is your issue.  I recommend using the
built-in support so your system matches the binary packages you are

> So far pkgsrc provides the most working software, but is also in a
> slightly inconsistent state with packages requiring others that are
> not available or not compiling in a current quarterly release. So I
> was forced to mix old and new releases to get some stuff working.

Well, not quite.  Mixing branches takes you into undefined behavior
territory.  It might work and it might not.

You can also checkout pkgsrc HEAD and build that.  Then you can fix
what's wrong (often upstream things) and that will make the next branch

> This was under the impression that a quarterly release is some kind of
> a stable and checked thing, when it really seems to be just a snapshot
> of a quarterly cvs state.

It is more towards stable.  While we do simply make a branch, we have a
period leading up to it where packages don't get updated, and people try
to make everything work.  With 20K packages and 20 operating system and
N cpu types per OS, it is infeasible to check everything.  Not that many
people build for sparc64, so upstream packages that don't build on that
tend not to get noticed and fixed.  If you look at the NetBSD 9 amd64
build results for 2020Q2 you'll see that almost everything builds.

> I am  not using cvs because the old machines are slow and I am in fear
> of constant recompiling on every slight update.
> This might change once NetBSD starts to support sparc64 T1 - T5 cpus.
> Fast and parallel compiling should be possible then.

What I would recommend is:

  1) if there is a binary build of a quarter, check out that quarter, and
  also install binaries

  A) if there is a package that is missing, try to build it, figure out
  what's wrong, and build it (on the branch).  merge the patch to HEAD
  and send that in.

  B) Alternatively,update that package to HEAD (with -A in a subdir).
  Note that this is not really a good idea, but if you lack adequate CPU
  time (which I believe; I ran a sparc classic until 2017), you are left
  with only more bad and less bad choices.  Then try to build and fix.
  You may have to update mk, and other things.  Harder usually, but the
  newer upstream version might have fixes.

  C) build the upstream package outside of pkgsrc.  Send fixes to them.
  Apply them to pkgsrc as patches once you understand.

> So all in all i am pleased. pkgsrc is currently the best way to have a
> modern desktop and software on these machines.

I agree.  I think you are struggling less than you'd be without it!

Attachment: signature.asc
Description: PGP signature

Home | Main Index | Thread Index | Old Index