On Fri, Feb 12, 1999 at 05:01:56PM -0500, Ben Collins wrote: > What we need is to not have infinite numbers of libgtk1.1.x libs in the > distribution. Stick with libgtk1.1 and use shlibs to ensure things get > recompiled against them. I would much rather have one lib and many > programs that break on the next release than tons of libs _and_ still > many broken programs as well as a mess on my system.
I think that we should decide every <some time period> that we use at that time current version of GTK+ (or any other lib) on all packages that depend on it. For example (just theorethical): today is fourth of october, and we decide that the current orange (the current distro marked unstable) packages of libslappysquirel should be packaged. The maintainer releases the 'hold' button :) and uploads the current 0.453.24 version, and then presses the 'hold' button again. :) All the packages get recompiled with this version and everything works. Time passes, and new versions start forming a big heap. But we don't do anything. We just wait the nineteenth of october comes, and that day the maintainer again does that releasebutton-compile-upload-pressbutton thing. All the packages get recompiled and everything works. I'm sure that by now everyone understood that how inefficient would this be in practice. First, there is chance that on the 'picking' day we get a totally broken version. Then there is chance that we hit a semi-working version - it works on some packages, on some it doesn't. Then there is chance that we can't get the time right, and a lot of maintainers don't recompile in time, and we have to do NMUs, making them upset etc. Not to mention that all porters won't be able to catch up with all of it always... The smartest thing to do - which reminds me on a startrek voyager episode - is doing nothing. It is an **unstable** and **unguaranteed for** portion of Debian. If you want it, you just have to fight with it. Once we see that there is too much functionality from those new apps being unused, we just declare a freeze, and clear things up, as we did for slink. -- enJoy -*/\*- http://jagor.srce.hr/~jrodin/