| 1 |
Kurt Lieber wrote: |
| 2 |
> I personally don't like that idea and I'll give you a real-world example |
| 3 |
> why. We have three web nodes atm. They all run the following software: |
| 4 |
> |
| 5 |
> AxKit 1.6.1 |
| 6 |
> libxslt 1.0.31 |
| 7 |
> libxml2 2.5.6 |
| 8 |
> |
| 9 |
> That particular combination works. I know it works. It has worked for |
| 10 |
> months. However, if I upgrade either libxslt to 1.0.33 or libxml2 to 2.5.8, |
| 11 |
> Weird Stuff starts happening and my life quickly becomes unpleasant. I'm |
| 12 |
> sure the issues are fixable, but the point is that even minor version bumps |
| 13 |
> can cause serious problems with production systems. In my mind, that |
| 14 |
> defeats the purpose of a stable/frozen tree. |
| 15 |
|
| 16 |
I agree with you that version bumps like that shouldn't be introduced |
| 17 |
into the stable tree. However, in order to avoid forcing admins to use a |
| 18 |
certain version of a package, when the stable tree is released there |
| 19 |
should be multiple stable versions of ebuilds in that portage tree. i.e. |
| 20 |
backwards compatibility in case the newest revision doesn't quite fit |
| 21 |
their needs. Of course you wouldn't want to include back versions that |
| 22 |
have security issues - or should you, but with a warning? |
| 23 |
|
| 24 |
~Mike Stewart, been lurking for a while |
Archives