Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Using NetBSD’s pkgsrc everywhere I can

rubenerd.com

Post reply on HN
Print view View original

61–70 of 80 posts

Re: Using NetBSD’s pkgsrc everywhere I can

#61

Post by klibertp »

jperkin wrote: post #58
klibertp wrote: post #56

From pkgsrc homepage: > You can checkout pkgsrc HEAD with CVS: ...really? Not even Subversion, but CVS?

The repository of record is CVS, but you can - like many of us do - use either the hg export ( https://anonhg.netbsd.org/pkgsrc ) or GitHub ( https://github.com/netbsd/pkgsrc ) instead. At some point we will transition the repository of record to something else, but it's being done carefully. We want to do it right, and there aren't many volunteers willing help with the work.

No, I was just surprised - I don't know anything about NetBSD (nor pkgsrc for that matter), but I worked with FreeBSD some 15 years ago and there were plans to move to SVN even back then. A quick search told me that the switch was completed in 2008 (a little bit after I left, begrudgingly, for Linux).

What challenges are there in switching to another VCS? Is the difficulty coming from the need to preserve history, or the need to re-evaluate workflows around the repo, or something else entirely?

Re: Using NetBSD’s pkgsrc everywhere I can

#62

Post by wsfull »

washbear wrote: post #60
wsfull wrote: post #54

Earlier quoted context omitted.

Care to be more specific than "underlying stuff". The code and design of xbps looks nothing like the code or design of pacman or apk.

Actual package recipes. BSD-style packaging systems are written in BSD make using a mk/ framework rather than Arch-style shell scripts. If a package already exists for FreeBSD Ports I would check that first because it's much more similar to what I'm used to. Fundamentally pkgsrc is built on very low level tools, awk, shell, make, cwrappers, and pkg_install, although you can manage it with high-level ones (obviously p…

Why are you comparing pkgsrc to pacman. The orginal comparison suggested in the parent comment was between xbps and nixpkgs or other Linux package managers.

pkgsrc boostraps itself using a program called "boostrap" in the pkgsrc directory. It builds a version of NetBSD's GCC toolchain and has no reliance on the host's userland. IME, this is very reliable and is its single greatest strength. Beyond that, pkgsrc is only as good as the build processes chosen by the author(s) of the software being built. These of course vary widely in sanity and depending on the packages one is building the otherwsise sane pkgsrc build process can quickly become a black box with packages that pull in many dependencies. It does break sometimes, but this is a fault of the target software authors, not pkgsrc. pkgsrc is first and foremost a system for building packages. Linux distributions OTOH tend to be much more focused on binary package managers. Most Linux users do not build packages from source. There is really no comparison.

Your comments do not sound like those of a daily NetBSD user. I have been one for the last 15 years and am therefore all too familiar /usr/share/mk. Most Linux users do not seem very comfortable with BSD makefiles.

Re: Using NetBSD’s pkgsrc everywhere I can

#63

Post by washbear »

wsfull wrote: post #62
washbear wrote: post #60

Earlier quoted context omitted.

Actual package recipes. BSD-style packaging systems are written in BSD make using a mk/ framework rather than Arch-style shell scripts. If a package already exists for FreeBSD Ports I would check that first because it's much more similar to what I'm used to. Fundamentally pkgsrc is built on very low level tools, awk, shell, make, cwrappers, and pkg_install, although you can manage it with high-level ones (obviously p…

Why are you comparing pkgsrc to pacman. The orginal comparison suggested in the parent comment was between xbps and nixpkgs or other Linux package managers. pkgsrc boostraps itself using a program called "boostrap" in the pkgsrc directory. It builds a version of NetBSD's GCC toolchain and has no reliance on the host's userland. IME, this is very reliable and is its single greatest strength. Beyond that, pkgsrc is onl…

> Why are you comparing pkgsrc to pacman.

The original commented suggested that XBPS was similar to pkgsrc. I suggested that XBPS has far more in common with Arch Linux's package manager than pkgsrc or anything else in the BSD world. As you yourself note in your next paragraph...

> Your comments do not sound like those of a daily NetBSD user.

I have commit access. Since three years ago. My name is on the latest release announcement.

You prick.

Re: Using NetBSD’s pkgsrc everywhere I can

#64

Post by johnklos »

kelp wrote: post #38
znpy wrote: post #24

Earlier quoted context omitted.

> pkgsrc doesn’t have Apple M1 binary packages available yet. basing this reply on my past experience with pkgsrc (in a netbsd or linux environments though) as long as you can point pkgsrc to a decent compiler and it can complete its bootstrap phase, it'll likely work.

That sounds right. But then I'm having to compile all the packages I need, which makes it even much much slower than brew when binaries are available.

Compiling on an M1 is too slow? ;)

Re: Using NetBSD’s pkgsrc everywhere I can

#65

Post by pxc »

eddieh wrote: post #41
kelp wrote: post #15

Earlier quoted context omitted.

I dislike it because it’s really slow to do everything. Even printing help text is slow. Contrast with pacman on Arch, which is incredibly fast at nearly every operation. Unfortunately I’ve found all the package managers for macOS to be lacking. brew is slow, but has packages for most things and generally up to date. fink packages seem a bit out dated last I checked. At least the ones I cared about. MacPorts is also…

Nix is probably the slowest and is missing many packages. It's Kool-Aid for the cool kids. MacPorts was good until everyone started using Homebrew. Homebrew has some weird quirks that drive me crazy, but it mostly works and is up to date. I tried pkgsrc and liked it, but a few common packages were weirdly named and it didn't have some Mac specific stuff. Some new package manager that's a mix of pkgsrc, brew, and MacP…

> Nix is probably the slowest

Nix evaluation can be slow sometimes, but installation is generally relatively fast, since everything in Nix is fully parallelizable. It's generally several times faster than apt, for installs that involve multiple large downloads, for example, and historically it's also faster than pacman.[1] (I think this is probably no longer the case with Pacman 6.0, which finally parallelizes downloads. In that case Nix evaluation time probably dominates.)

I imagine what you're identifying as slow is searching through Nix packages. On the old/stable release of Nix, you use something like `nix-env -qaP` for this, and that requires evaluation of every package in Nix, and can take a long time. `nix search`, however, is extremely fast on the unstable releases of Nix.

A Nix search using the old method is extremely slow, > 7 seconds:

  I  ~  time nix-env -f '' -qaP libreoffice
  libreoffice                  libreoffice-7.0.4.2
  libreoffice-still            libreoffice-7.0.4.2
  libreoffice-still-unwrapped  libreoffice-7.0.4.2
  libreoffice-fresh            libreoffice-7.1.2.2
  libreoffice-fresh-unwrapped  libreoffice-7.1.2.2
  libreoffice-qt               libreoffice-7.1.2.2

  ________________________________________________________
  Executed in    7.31 secs    fish           external
    usr time    6.79 secs  335.00 micros    6.79 secs
    sys time    0.52 secs   67.00 micros    0.52 secs
A Nix search using the new method, which leverages cached evaluation of Nixpkgs, takes about half a second:

   nix-shell -p nixUnstable --run fish
  
   time nix search --experimental-features 'nix-command flakes' nixpkgs libreoffice
  

  * legacyPackages.x86_64-linux.libreoffice (7.0.4.2)
    Comprehensive, professional-quality productivity suite, a variant of openoffice.org

  

  ________________________________________________________
  Executed in  576.30 millis    fish           external
    usr time  561.00 millis  252.00 micros  560.75 millis
    sys time   16.07 millis   55.00 micros   16.01 millis
And installation, in either case, is pretty fast. It takes a few second to install, for example, Libreoffice on my system, with the vast majority of the time taken up being the download:

   time nix-env -f '' -iA libreoffice
  installing 'libreoffice-7.0.4.2'
  these paths will be fetched (153.59 MiB download, 574.57 MiB unpacked):
 
  copying path '/nix/store/8yq9h91bsbgi62dhvh4xfqxvhq58b5y4-libreoffice-7.0.4.2' from 'https://cache.nixos.org'...
  building '/nix/store/nhmf4ak414lrzy3387kbsx8brm8hckds-user-environment.drv'...
  created 68 symlinks in user environment

  ________________________________________________________
  Executed in   21.32 secs    fish           external
    usr time    1.34 secs    0.00 micros    1.34 secs
    sys time    0.43 secs  521.00 micros    0.42 secs
(I tried for a bit to get Linuxbrew installed so I could test the same functionality with it, but Homebrew isn't portable enough to work on NixOS, since it hardcodes a ton of command and interpreter paths to files that don't exist on some distros.)

—

1: https://michael.stapelberg.ch/posts/2019-08-17-linux-package...

Re: Using NetBSD’s pkgsrc everywhere I can

#66

Post by pxc »

mixmastamyk wrote: post #46
pxc wrote: post #25

Earlier quoted context omitted.

It's got a larger user and contributor base on macOS than competing package managers, and that works in its favor, especially in terms of package selection. I'm not a total hater; there are people I respect who prefer Homebrew over tools that I like better for reasons I understand. And package management is a peculiar interest of mine, so I care a lot about details and there isn't any package management system that t…

How are you handling the read only root folder with nix?

You mean for installation on macOS? For current versions of Nix and macOS, you just invoke the installer with an additional command-line flag at installation time, per the manual[1]:

  sh
I don't remember whether I actually did this on my system. I think I manually created an additional volume for /nix, but encrypted it. That approach is also now described in the manual, should you prefer it.[2]

(Unencrypted should be fine anyway, as the Nix store is designed/assumed to be public (world-readable). Packages and tools in the ecosystem never put secrets there.)

—

1: https://nixos.org/manual/nix/stable/#sect-macos-installation

2: https://nixos.org/manual/nix/stable/#sect-macos-installation...

Re: Using NetBSD’s pkgsrc everywhere I can

#67

Post by pxc »

washbear wrote: post #48
fiddlerwoaroof wrote: post #9

Earlier quoted context omitted.

nix does all three of these, I think.

It is nowhere near as cross-platform as pkgsrc - it only really supports macOS and Linux.

I love Nix, but this is true. The cross-platform support for pkgsrc is outstanding, and Nix's is still relatively limited.

Nix has better cross-compilation support is a little bit better than its native support, in terms of cross-platform coverage. But even then, I think, pkgsrc's platform coverage is in a different league. :)

Re: Using NetBSD’s pkgsrc everywhere I can

#68

Post by pxc »

johnklos wrote: post #12
fiddlerwoaroof wrote: post #9

Earlier quoted context omitted.

nix does all three of these, I think.

How does one bootstrap nixpkgs from source? Trying to install nix gives: sh install-nix-2.3.10 install-nix-2.3.10: sorry, there is no binary distribution of Nix for your platform

There's partial support for platforms besides macOS and Linux, but I'm not sure the state of it or how practical it is.

What platform are you hoping to build Nix on?

Re: Using NetBSD’s pkgsrc everywhere I can

#69

Post by pxc »

1vuio0pswjnm7 wrote: post #42
xaduha wrote: post #7

Earlier quoted context omitted.

I'd try nixpkgs before trying pkgsrc if for some reason I wasn't satisfied with ones that come with the distro. Not sure why BSDfying packages is desirable by itself.

Nothing against nixpkgs, but if the user is curious about how things are done in BSD perhaps he should try xbps before nixpkgs. It was written by a former NetBSD committer who wrote some useful programs for NetBSD's userland. I am biased perhaps but I believe it is faster than any other Linux package manager. Always looking for something faster so I am welcome to being proven wrong on that. https://github.com/void-li…

Can xbps be used on foreign distros like pkgsrc? I'd be down to try it out on Ubuntu and NixOS if it supports that

Re: Using NetBSD’s pkgsrc everywhere I can

#70

Post by pxc »

jperkin wrote: post #52
johnisgood wrote: post #45

Earlier quoted context omitted.

pkgsrc does work on Linux, but pkgin does not. I have no idea how to update my mirror and so forth using pkgsrc alone. Do not I need pkgin? I cannot do `pkg_add` at all. I tried to make pkgin work, too, and I think it is possible to make it work with libbsd but I do not have the time. I wonder if anyone has done it.

I am the pkgin maintainer, and would be interested to hear about any issues you have building pkgin. It should build on any of the 23 platforms that pkgsrc supports, including Linux. I even offer daily binary package builds for CentOS here: https://pkgsrc.joyent.com/install-on-linux/ Feel free to open up an issue at https://github.com/NetBSDfr/pkgin/issues and we can take a look.

Those binaries even sometimes work on Ubuntu, with a little manual linking and good luck, even though it's a total abuse. :D
Post reply on HN