And there is interesting file /var/db/pkg/auditfile. For example:

freetype2 from pkgsrc has version 2.4.11. After installation /var/db/pkg/auditfile contains next line:
freetype2<2.4.11|http://portaudit.FreeBSD.org/1ae613c3-5728-11e2-9483-14dae938ec40.html|freetype — Multi\
ple vulnerabilities.

If I try install xorg from dports then installation fails. Dports has freetype2 with version 2.4.9_1 :(

I’ve been committing furiously to pkgsrc for about year. I raised the package count by a couple of thousand in that time. I’ve been working dports for a couple of months, and we’ve just passed 17,5000 ports.

I recognized that ports was not as incompatible for dragonfly as most assume. I thought we could get over 12,000 packages pretty easily and this turned out to be a correct assessment.

Regarding the political issue: At the end of the day, pkgsrc exists to serve NetBSD and most of the developers contribute accordingly. Every now and then a suggestion to spin it off as a separate project (make it neutral, make it easier for others to get a commit bit) comes up but is always shot down. I believe this needs to happen but I am skeptical that it will.

The reaction to support gcc47 on DragonFly proved to me that in reality DragonFly is a second-class citizen. On paper, it’s equal footing, but that is where it ends in my opinion.

I have brought up the QA issues with commits that break non-NetBSD systems a few times and been shot down every time. The official statement paraphrased: Yes, breakage happens, a lot. Non-NetBSD are expected to follow the original committer and clean up his mess. Testing is not required”.

So basically: if there is any testing, it’s NetBSD only (and probably only a small subset of archs for NetBSD). As seen recently with the webmin fiasco, the guy that causes massive breakage isn’t required to fix any of it. That’s not how I roll — If I broken in excess of 40 packages I would revert my commit with significant embarrassment.

Carlo is correct that theoretically we can set up the same “staging” scheme that I’ve set up for FreeBSD. But why bother?

DragonFly has used pkgsrc for at least 6 years. It’s not like pkgsrc didn’t get a fair evaluation. I have several developer-based gripes but dports is about user-facing merits.

The good news is that users aren’t forced to use either system. Both are supported. It is likely that my support of pkgsrc will reduce to Ada packages and fixing unacceptable regressions but I probably won’t fix too many more leaf packages. My time is better spend on dports.

An automated build system for pkgsrc would be nice.

– pkg(8) seems like a welcome addition.

– It sounds like some of your grievances could be solved with an automated build attempt/bugreport whenever there is a commit. I take it many pkgsrc developers only test on NetBSD?

I’m not really sure what to think about the other things you mentioned (and some of them sound a tad on the subjective side) — I’m afraid I don’t have enough experience with DFly to be able to judge by myself.

I think both ports systems could use both a new frontend and a backend (The building can still be done with the make rules, but everything else, starting from the dependency resolution, should be done by something else.) Maybe pkg(8) can fill that slot?

Then they came up with that rolling_replace tool (I think of it as a hack) but you can easily find yourself in a situation where you can’t even delete the old package and the whole repository is messed up.

with pkg you also get sqlite as the package database and it’s lightning fast. Many pkg_* tools are built in, like “pkg which” and that is fantastic. You can pass any path to pkg and it will tell you what package installed it. Highly useful. That kind of stuff is why I say “it’s integrated” and not an optional bolt-on. Pkgsrc could do the same, but they need to settle on an official approach and tool and fix the mk files to accomplish it.

Pkgsrc was more designed to only get binaries as evidenced by the very poor experience with updating from source. DPorts is also focused on the binary-only experience, but building from source and updating from source should be less problematic if that is what you want to do.

It also has a clear binary packaging system and upgrade method in place. There isn’t really one for pkgsrc, or rather there’s a bunch, all of which don’t quite cover all the issues. Pkgin handles only binaries, which don’t always build from quarterly release to quarterly release as noted above. pkg_rolling-replace only builds from source, and requires some fiddling with packages for name changes, and so on. The one canonical way that comes with pkgsrc, ‘bmake replace’, isn’t recommended.

This sort of binary packaging system is in theory possible with pkgsrc too, but John Marino’s going with FreeBSD ports for various reasons, including the overall higher count of packages.

I will not even talk about behind-the-scene benefits that most users wouldn’t be aware of. Nor will I talk about which is superior technology because this is a highly biased topic (let’s just say that I don’t believe “the gap” is between pkgsrc and ports is as big as pkgsrc devs say it is)

Frankly, I don’t see why this is a mystery.
I have a commit bit to pkgsrc and it’s been indicated that I can get a commit bit to Ports so I think I have better good insight into both systems.

All the linux emulation packages are i386 only and they haven’t been attempted yet. They are coming though.

I think the port count is over 12,000, but that’s a first pass of successful builds. The number is probably technically lower because of programs that build successfully but do not run correctly. We’ll find out in the coming weeks.

FreeBSDs new package management tool pkg seems like a big leap forward, too.