| 1 |
On Saturday, September 11, 2010 22:51:23 Ryan Hill wrote: |
| 2 |
> On Sun, 12 Sep 2010 20:59:25 +1200 Alistair Bush wrote: |
| 3 |
> > There should be nothing stopping a user from running a mixed arch/~arch |
| 4 |
> > system. Those problems just point to our dependency information not |
| 5 |
> > being recorded correctly. It might be understandable that this info |
| 6 |
> > can be incredibly hard to get correct but that doesn't mean it isn't a |
| 7 |
> > valid bug. |
| 8 |
> |
| 9 |
> It's invalid as soon as you bring system-set packages into the mix, which |
| 10 |
> falls outside of dependency correctness. |
| 11 |
> |
| 12 |
> The trouble is knowing if this applies in the situation you're looking |
| 13 |
> into. |
| 14 |
|
| 15 |
indeed. for people who disagree, feel free to go through every single stable |
| 16 |
package in the tree that breaks with glibc-2.12, or linux-headers-2.6.35, or |
| 17 |
make-3.82, or xxx and add a blocker against the newer versions of these |
| 18 |
packages. and then do it every time we get a new version. |
| 19 |
|
| 20 |
or, let's keep our sanity and continue doing what we've been doing over the |
| 21 |
years -- stabilize newer versions of packages that do work with the stable & |
| 22 |
unstable versions of the packages they build against. |
| 23 |
|
| 24 |
people who install unstable core system packages way before we're interested |
| 25 |
in stabilizing and then file bugs that only apply to stable get INVALID->their |
| 26 |
problem. especially when a simple bugzilla search would have told them that |
| 27 |
their issue is already fixed in the unstable version of whatever package is |
| 28 |
failing for them. |
| 29 |
-mike |
Archives