2010/5/1 Marc Espie <[email protected]>: > 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.
Hmmm. Difference in WANTLIB's (while pkgnames are same) means either : 1. Corresponding WANTLIB in package "a" is less than in "b". This way we can be sure that "b" is newer than "a". So no bump required. However, if 'a' has libxxx WANTLIB newer than 'b', and 'b' has libyyy WANTLIB newer than 'a' then (something gone wrong, but nevermind) and bump required. 2. If (1) did not help, "a" contain WANTLIB that "b" doesn't. If we decide as a global rule that this means "'a' is newer" then pkgname bump will be required only when actually 'b' is newer. Yes, those rules will not completely cancel bumps, but at least reduce them. Sorry for any stupidity. > 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...
