On Sat, Jan 02, 2010 at 09:42:37AM -0600, Chris Bennett wrote: > > > Marc Espie wrote: > > > >You will possibly retrieve more packages than you strictly need, since > >pkg_add looks inside packages, and doesn't retrieve them unless they have > >different signatures. > > > > > OK, I am watching very carefully as I am updating, and I can see > that, despite having the smae name and version number, several > packages are being downloaded. > These new downloads do not have the same file size. > > Obviously this is due to a change in signature. > Now it's quite clear that anything other than pkg_add will be a > waste of time. > > But I do have a question. > What makes a package get a version number change instead of a > signature change? > > Obviously -current packages are always changing, but does a version > change mean that it is temporarily stable?
Packages have dependencies. The signature is a snapshot of what was used to build the package. Package version numbers change whenever the port itself changes. This cannot take into acount dependencies, hence the signature. For instance, take the gimp package, currently at version 2.6.7p3. gimp depends on the jpeg library, so its signature contains markers for the jpeg package, and for the library proper (on shared archs machines). Say it's been built against jpeg-6bp5 / libjpeg.so.62.0. When jpeg gets upgraded (which happened recently, it went to jpeg-7 / libjpeg.so.63.0), the gimp package will change: the new package will be built against the new library. BUT the package name won't change. It would only change when someone modifies something in gimp proper. Anything else is impractical. You cannot bump every package in the tree that depends on jpeg every time jpeg changes (actually, I think the freebsd people try to do something like that, and it generates a huge amount of noise). On the other hand, package builds occur every few days/weeks on most architectures. And so, the gimp package you will see will be different from the one of a few days ago (most certainly a different size because of embedded datestamps which will compress slightly differently). But if none of its dependencies have changed, then there's no reason for you to upgrade...
