On Thu, Aug 16, 2001 at 12:55:53PM -0400, Alan Shutko wrote: > "Keith G. Murphy" <[EMAIL PROTECTED]> writes: > > No, I honestly don't think it's that at all. The problem is, once you > > let the package maintainers update stable on the fly with bug fixes, how > > do you ensure they don't break something major (which may not even be > > the package itself in isolation, but interaction with others)? > > OTOH, it would seem to be feasible to update and test packages which > are leafs on the dependency tree. How would they affect packages > which don't depend on them? > > For example, it would seem reasonable to upgrade Gnus, nethack or sl, > which don't seem to have any other packages depending on them.[1]
Except that when you're doing that you also have to take into account reverse-depends; what if your new version of Gnus required a bug-fix to Emacs, or even broke part of Emacs due to something new that it installed? And also, you might end up inadvertently breaking the package on other architectures, or finding out that the package's build system was broken enough that you had to do quite a lot of hacking to make it work other than by luck depending on how accurate the build machine's clock was (this has really happened to me), or building it with extra packages installed that affected the build in previously unknown ways and ending up with a package that didn't work on some people's systems even though it worked on yours, or even one that broke other packages due to inadvertently installing an extra file, or ... Anyway, enough of the run-on sentences. All of these are of course bugs which should be fixed, but preferably in unstable when fewer of the world's eyes are on it. As somebody else said, the solution is to achieve a faster stable release cycle. > This would seem to allow the updating of many desktop-type apps (as > long as they worked with the existing version of the libraries they > depend on). The upgrades that most people clamour for are things like a newer version of GNOME in stable, which isn't practical as it introduces so many new library versions. In practice the constraints are too tight to be very useful. Some people maintain unofficial repositories of programs compiled against stable to get around this; it doesn't matter so much if they break. -- Colin Watson [EMAIL PROTECTED]
