#pkgin — Public Fediverse posts

@AFresh1 on #NetBSD :

#sysupgrade auto https://nycdn.netbsd.org/pub/NetBSD-daily/netbsd-X/latest/amd64

For packages :

#pkgin update
#pkgin full-upgrade

Edit:

For packages only #pkgin upgrade
as pointed by @jperkin Thanks :)

pkgin 25.10.0 released.

Fixes an issue where changes to the pkgdb outside of pkgin operations (e.g. manually running pkg_add) could affect subsequent upgrades and lose autoremove information.

I'll get this into the SmartOS and macOS trunk builds over the weekend.

#pkgin #pkgsrc

pkgin 25.5.0 released.

Includes some important fixes to SUPERSEDES and CONFLICTS support, and "upgrade" will now update any core package tools first.

Should correctly handle the recent php-X.Y -> phpXY-X.Y renames, and fix some other corner cases.

https://github.com/NetBSDfr/pkgin/blob/master/CHANGES.md#version-2550-2025-05-19

#pkgsrc #pkgin

Next version of pkgin will check for upgrades to any installed packaging tools first.

https://github.com/NetBSDfr/pkgin/commit/e5849d8f52215b36a8f8ed6d80e31c15178cff81

Wishing I'd done this sooner so that upcoming fixes for SUPERSEDES would be automatically handled :( Oh well, hopefully will still prove to be useful in the future (or maybe not!)

#pkgin #pkgsrc

Does anyone know how install certificates so I can use #pkgin? 🙏

I kinda like the fact that #NetBSD does very little but sometimes it raises very high the learning curve... 😵‍💫

p.s. I completely forgot how slow was the #RPI 2 😩

@archer72 On #FreeBSD, you'd use #pkg.

#pkg_add is a predecessor of #pkg. #pkgin is a part of #pkgsrc, which you can use on #FreeBSD if you really want to. #NetBSD folks might be able to tell you more about #pkgsrc.

For anyone using my macOS binary package repository, I've switched to building against MacOSX12.3.sdk.

Build results look good, and over 24,000 packages are available for both arm64 and x86_64.

Full details on why I had to change, and how to switch to the new repository, are in my post to pkgsrc-users:

https://mail-index.netbsd.org/pkgsrc-users/2024/04/19/msg039367.html

The 11.3 repository will no longer be updated, but will remain available for anyone unable to upgrade past Big Sur.

Any problems, let me know!

#macos #pkgsrc #pkgin

Updated #pkgsrc bootstrap kits now available for macOS, available as usual from https://pkgsrc.smartos.org/install-on-macos/

These include the new and improved #pkgin 23.8.1.

No need to install new bootstrap kits if you already installed an older one, but you may want to run:

$ pkg_add -U pkg_install pkgin

prior to running "pkgin upgrade" so that the upgrade is performed using the latest tools.

It's a pity that Mastodon lacks quote tweets, but in addition to the post I boosted yesterday, I just wanted to say my own thanks for #DTrace reaching 20.

I use it all the time, and struggle when working on other systems that do not have it. Only yesterday I wrote a quick script to verify a code path that lead to this fix: https://github.com/NetBSD/pkgsrc/commit/def71d1c1f988e3a2cf3bb86716a2937ce6f48fc.

It has found significant performance wins in #pkgsrc and #pkgin, fixed numerous bugs, and helped me understand systems.

Thanks @bcantrill and @ahl!

Ok, with a boatload of fixes and a performance improvements of up to 2,500x I've released #pkgin 23.8.0!

https://github.com/NetBSDfr/pkgin/blob/master/CHANGES.md#version-2380-2023-08-16

There's still a bunch of things to do, but they can wait for future releases.

I've updated the #pkgsrc package and will be rebuilding binary package sets over the coming days.

As part of my recent #pkgin work I came across another optimisation for "pkg_admin rebuild-tree" using #DTrace that makes it a further 12x faster on my test system.

http://mail-index.netbsd.org/tech-pkg/2023/08/07/msg027952.html

This is in addition to the 13x speedup I committed a few years ago:

https://gist.github.com/jperkin/98550d5bd07f4179ebfeea825fc3ec20

Reviews appreciated. #pkgsrc #netbsd

Not only was #Manta v1 awesome for having jobs, the marlin image provides a superb environment for testing the new #pkgin code, given there are over 12,500 packages installed.

I'd say the results are looking pretty good:

$ time ./pkgin-22.10.0 -n ug
real 54m10.021s
user 53m42.252s
sys 0m21.575s

$ time ./pkgin-current -n ug
real 0m1.241s
user 0m1.086s
sys 0m0.145s

Under 1 second would be cool, and I think there are still some areas where improvements can be made.

#pkgsrc

As we near final approach for the next version of #pkgin I've put out a call for testing.

https://mail-index.netbsd.org/pkgsrc-users/2023/07/27/msg037830.html

There are a huge number of improvements coming, but despite fixing a lot of bugs I'm always a little terrified of breaking something, so it'd be great if any #pkgsrc users could help me out and give it a spin.

Thanks!

So grateful for investing time into writing the #pkgin test suite.

Required adding and rearranging code in pkgin itself to support various environment variables that allow us to run alternative packaging tools, as well as writing the test suite itself, which all took quite a bit of time.

But being able to write complex upgrade scenarios, and go quickly from hypothesis to fix, has paid off hugely. Plus the added confidence that all of the regression tests ensure I haven't broken anything.

Finally for this week I've fixed package ordering during install/upgrade. This resolves issues where install scripts run programs that depend on libraries that haven't been upgraded yet.

As an added bonus the streamlining improves performance quite a bit (upgrading 1,700 packages from 2020Q4 to 2022Q4):

$ ptime pkgin -y upgrade

real 41:06.80
user 28:52.80
sys 12:59.15

$ ptime ./pkgin-current -y upgrade

real 36:09.76
user 24:32.55
sys 11:58.56

#pkgsrc #pkgin #netbsd

Reworked the recursive dependency discovery to make the code a lot more readable, as well as improve performance.

$ ptime ./pkgin-22.10.0 -n upgrade

real 3:29.880475370
user 3:29.329552124
sys 0.353450635

$ ptime ./pkgin-current -n upgrade

real 12.324068349
user 11.972102324
sys 0.166771212

I'd say we're making progress!

#pkgsrc #pkgin

After some more #DTrace analysis and code reading, found another easy optimisation win in the pattern matching code, for a further 2x speedup.

Next up some database optimisations which will hopefully get us to around 8x combined speedup, as well as helping with future development work.

#pkgsrc #pkgin

After maintaining #pkgin for a few years, there's still a bunch of low-hanging fruit for cleanup and optimisation.

While working on SUPERSEDES support, I was curious as to why the dependency calculation takes so long.

Re-ran it with #DTrace, saw break_depends() taking up 55% of the runtime. What does it do?

Turns out, nothing. Various changes over the years, notably refresh support, have made its calculations obsolete.

Nice easy 2x performance win and much easier-to-understand code path.

Replaced old #ThinkPad T41 broken hinge. With 2GB of RAM and a 1.6Gz Pentium M, realistic software options are... limited

Installed the latest #NetBSD 10_BETA, then used #pkgin to see about basic web browsers

#netsurf - fastest way for basic webpages

#ArcticFox - hits the sweet spot for older/constrained machines

#Firefox - 92 is almost usable in 2G, 102... not so much. I stopped there :)

For its time (2003) the T41 is an amazing laptop. Plus that screen ratio #chefskiss

#retrocomputing

Upgrade packages with pkgin to netbsd 9.0 #pentium3 #netbsd #pkgin #vintagecomputer

Upgrade packages with pkgin to netbsd 9.0 #pentium3 #netbsd #pkgin #vintagecomputer

Upgrade packages with pkgin to netbsd 9.0 #pentium3 #netbsd #pkgin #vintagecomputer

Upgrade packages with pkgin to netbsd 9.0 #pentium3 #netbsd #pkgin #vintagecomputer

Upgrade packages with pkgin to netbsd 9.0 #pentium3 #netbsd #pkgin #vintagecomputer

I, alas, don't get the luxury of using #netbsd as much as I'd like. Some of that is most certainly down to personal preference, and others are due to the overall slow-pace of change, relative to its cousins #openbsd and #freebsd.

But when I were using #netbsd, I really did love #pkgin (https://pkgin.net/). I did contribute to this many moons ago -- and to this day, it represents the simplicity and thoughtfulness that any package manger should. The #ui is the important thing here -- and #pkgin gets that right, especially for its primary target audience of #netbsd.

I know that #freebsd has #pkg -- which does a very good job, but something always keeps me looking at #pkgin -- even though, I also have code in #pkg.

#openbsd is the real outlier here -- their pkg_* tools are still perl-based, but like the dark horse they are, are maintained well, and really functional.

I've heard it argued that in the #linux world, the different distros keep people apart due to how they handle package management, even as far as to suggest that the programming language is a key factor here.

I say, "eh?", but even then, I'd still gravitate toward *BSD...