On 2010/05/01 21:57, Vadim Jukov wrote: > 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. >
WANTLIB aren't really a problem, it's a pain to sync them sometimes but it's not too bad if the work is shared, and bumping PKGNAME is minimal extra work after regenerating the WANTLIB lines. The real problem is the case where you touch one thing and have to bump hundreds of ports in one go as a result (typically a module with a RUN_DEPENDS line that changes, but the other one that comes up semi- regularly is when Perl in base is upgraded - sometimes this means that XS modules must be recompiled with the new version) But really the only thing badly affected by RUN_DEPENDS bumps is Python pkgspec changes (affecting ~500 ports), which is annoying but doesn't happen often - I think the Perl thing could be automated (after doing it once by hand) by having perl.port.mk add a fake WANTLIB on libperl for SHARED_ONLY ports to ensure the signature changes (it would show as Extra in lib-depends-check but that's not really a problem).
