Warning: highly technical message. If you don't port things regularly, this probably doesn't concern you.
This message in response to a discussion with a few porters, about the chore of updating WANTLIB, and having to bump pkgnames. At first, I didn't think too much about it, and I said "oh, we can probably get rid of that requirement". Fool that I am, I'm afraid bumps are here to stay. Current framework works like this: pkgnames correspond to a given package, with all the information in the packing-list. This includes @wantlib and @depend annotations (which correspond to WANTLIB/LIB_DEPENDS/RUN_DEPENDS). There's a tool in the ports tree that checks stuff: it's called PLIST_DB, and all porters are encouraged to activate it, so that the tree will refuse to build packages if the packing-list doesn't match the previous one. Of course, there are details that are allowed to change. For instance, you say you @wantlib on libc, and then the base system goes from libc.so.52.0 to libc.so.53.0 and you don't want to bump every single package. Hence, pkg_* has a notion of "signatures" (not crypto stuff, that's something different), built from the pkgname, and a snapshot of all that the package was built against (every shared lib version as recorded in @wantlib, and every pkgname as recorded in @depends). That way, pkg_add can now whether a package changed, even if the pkgname proper didn't change. PLIST_DB also has provisions to handle this: it doesn't record the "package signature" the way it's stored in the PLIST (it changes every variant string to "def" for that purpose). However, there's still a snag: updates should not downgrade. How do you know, out of two packages with different signatures, which one is the newest. Here, pkg_add proceeds cautiously: first it compares the pkgname itself, and then, if it is identical, it will look at the complete signature. If one signature is demonstrably older than the other, it knows what to do. But if anything else changes, then it can't actually decide. So, if you add WANTLIBs, or if you change the pkgspec in a RUN_DEPENDS, you're breaking pkg_add's algorithm... it does actually need the bump to be sure you don't actually downgrade your package. Note that, if you really understand this, you can probably figure out cases in which changing depends without bumping ought to work... For instance, assuming you want to change the python module, if you do so with a python package bump, this would probably be totally non-ambiguous. But this is really a special case, and I don't know how to change PLIST_DB to cope with that, and I'm not sure this is such a good idea. One alternate path would be to say "but I don't want to do pkgname bumps directly in the Makefile, I could have a separate mechanism that figures out p* numbers from different sources". There's only one showstopper with that scheme: I have absolutely no idea how to implement that while keeping most of the meta-information that's in the ports tree static. And we want static information ! The pkgsrc tree, where most of the info is dynamic, is waaays less efficient and a bitch to test compared to what we currently have...
