On Thu, Feb 09, 2006 at 09:34:54AM +0100, Martin Costabel wrote: > Daniel Macks wrote: > [] > >This falsely assumes that a .deb built for one dist will be the same > >as for another. > > Which, of course, has always been the fundamental assumption at the > basis of all of Fink's upgrade mechanisms when going from one tree to > another.
But it's known to be false. In most cases, the actual package contents are fine if they are already installed, but the dpkg bits around them are usually different. Some maintainers even always rev-up in 10.4T vs 10.3 just for safety even for ostensibly identical packages. > >There's some automatic dist-dependent built-time stuff > >done that may give a .deb under 10.4-T, for example, that isn't > >appropriate for 10.4, or a .deb under 10.x that isn't usable at all on > >10.y. It means that .deb for packages that are no longer appropriate > >at all in a new dist will still be easily installable. For example, packages built on 10.4T have prebinding routines added to PostInst while 10.4 does not. More severe is when a newer tree adds things that are incompatible with an older one. There are also automatic Depends added for the OS X major version, so foo.deb built on 10.4* cannot be installed on 10.3 even it was built from the same .info file. Sure, not many people downgrade, but once you wedge stuff into debs/ forever, all kinds of cross-dist badness accumulates. > >We've had many > >cases where a package gets out-of-sync (upgraded revisions) between > >two dists and eventually wind up with the same revision but different > >(sometimes *very* different) different dependencies and build options. > > "Many cases"? Until now, this would clearly have been considered a bug. > We did revision jumps of 10 or now 1000 precisely to avoid this situation. Doesn't mean it doesn't happen or that 10 is enough (in hindsight). Maintainer mistake (perhaps due to officially no-longer-supporting older dist) leads to new-dist rev-up by 1 vs old-dist. Lots of fixes to old-dist package only leads to convergence. That and also correctly updating two dists with rev-up in tandem (maintain separation) leads to old-dist overlapping where new-dist is or was. Yesterday everyone on 10.4T had to rebuild poppler to get out of the way of an approaching 10.3 package, which then had to leap-frog over where 10.4T had been. Right now g77 is present in 4 different revisions among 10.3&10.4T stable&unstable, with some rev-ups done solely to keep a high dist higher rev than a lower one as they gradually un-sync from each other and get dist-specific patches. It also happens in stable vs unstable, where one syncs them and makes gradual changes to unstable. Then someone fixes something in stable. Unless that fix matches the fixes and revs in unstable, we've got rev collisions and/or forced rebuilding of unstable just to get out of the way. I don't mean to ramble on here or whine about quality control, but just to illustrate that there are easy ways one can get a .deb of a certain %n-%v-%r left from one dist that doesn't even match the .info, let alone the dist-specific build product, that one would get in a different dist. Drawing a line and say "anything you install from now on will be consistent with the .info and automatic tree-specific features" keeps users from getting stale old .deb that don't. Users get more appropriate .deb and are less likely to get bitten by maintainer mistakes. It's a polite way to gradually refresh one's packages to the current dist. > If your argument is going to become accepted Fink policy, then we should > really stop any "upgrade matrix" related activities and instead > concentrate on implementing the most painless way of doing > "remove /sw && install new Fink distribution && install the equivalent > of the old installed packages list". If we don't mind forcing users to spend who-knows-how-many hours rebuilding stuff just to get back to where they were, which was likely to have been still functional and viable, that's fine. I don't like doing that to users, but it's certainly more foolproof than any other strategy...wish we had a bindist:( Well, we need to establish *some* strategy... dan -- Daniel Macks [EMAIL PROTECTED] http://www.netspace.org/~dmacks ------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642 _______________________________________________ Fink-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/fink-devel
