2010/5/1 Marc Espie <[email protected]>: > On Sat, May 01, 2010 at 08:46:39PM +0400, Vadim Jukov wrote: >> 2010/5/1 Vadim Jukov <[email protected]>: >> > 2010/5/1 Marc Espie <[email protected]>: >> >> On Sat, May 01, 2010 at 04:26:59PM +0400, Vadim Jukov wrote: >> >>> >> >>> 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. >> >> >> >> You're missing the point. Most trouble happens when we have to adjust >> >> wantlib after an X11 change or something. >> >> >> >> Generally, it goes from a set of WANTLIB to another one. >> >> >> >> Put it another way, first package has >> >> WANTLIB = a b c >> >> >> >> second package has >> >> WANTLIB = a b c d >> >> >> >> which is the newest one ? >> > >> > "By default", second is newer (empirical rule based on the fact that >> > software gets more complicated in time, not less). If this is not the >> > actual case, then pkgname should be bumped. PLIST DB could handle this >> > fact and allow replacing first packge by second but not vice versa. >> >> Better I'll explain using more details. >> >> Say, we have libs "libXfoo.so.1.0", "libXbar.so.0.0" and >> "libXcrap.so.0.0". Package "someprog-1.0" gets linked against them, >> this info is saved in PLIST DB. So far so good. >> >> Now we have updated X, and "someprog" get linked against >> "libXfoo.so.1.0", "libXcrap.so.1.0" and "libXbebebe.0.0". Here compare >> logic goes: >> >> 1. Set compare status as "same". >> 2. Verify libXfoo dependency: it didn't change, status is still "same". >> 3. libXbar was not found in new plist - oops, set status to "unknown". >> 4. And there is new one - libXbebebe. Still "unknown". >> 5. Finally got two different versions of libXcrap. Second plist >> contains newer version, status is "unknown" - set it to "update". >> >> Thus we (empirically) found that second package is newer. >> >> For the difference, if second package contains "libXfoo.so.0.0": >> >> 1. Set compare status as "same". >> 2. Verify libXfoo dependency: oops, first package contains "newer" >> dependency. PLIST DB should error out requiring package bump. > Yes, something like this might be feasible, but still, we end up with > very complicated rules, and people are going to fuck up...
Yep, and I'll be from the first ones that broke it. :( The better and more technically complicated way to deal I've seen requires: 1) creation of pseudo-packages for base system + X (just a list of libs will be enough for current task; using date and time as package version) and 2) saving package versions for each WANTLIB. This way, when in doubt (and _only_ then), we should use the package with more recent WANTLIB-package-version (errrr...). The bad things will happen if build machine gets partly back in time, but this is not a supported situation anyway.
