| 1 |
On 2017-05-09 10:12, Rich Freeman wrote: |
| 2 |
> Why not? If an arch is considered a non-security-supported arch |
| 3 |
> then you would just ignore it in a security bug. |
| 4 |
|
| 5 |
We dropped security coverage already for ia64 and are in the process to |
| 6 |
drop it for sparc as well. |
| 7 |
|
| 8 |
So how do you want to cleanup a package which is the last ebuild of the |
| 9 |
package and still marked stabled for ia64/sparc? You cannot. If you are |
| 10 |
lucky you would only remove a package without any rdeps. But in most |
| 11 |
cases you are breaking the tree. |
| 12 |
|
| 13 |
|
| 14 |
> Otherwise a revbump could break stage3 on those arches. |
| 15 |
|
| 16 |
Is this really a problem? What could happen: |
| 17 |
|
| 18 |
Worst case: Existing stage3 for this specific dev/exp architecture will |
| 19 |
be very old because any attempt to refresh the stage3 image will fail |
| 20 |
with a build error. However, the last working stage3 image won't go away |
| 21 |
until it was replaced by a newer working one... |
| 22 |
|
| 23 |
Also, is this different from current status? Not really: If this |
| 24 |
architecture would be capable to keep up with all the other major |
| 25 |
architectures the stage3 image would be in a current working state. |
| 26 |
Build errors would be solved in time. We wouldn't discuss dropping them. |
| 27 |
So we are only talking about architectures which have shown that they |
| 28 |
are not able to keep up. And those architectures are already lacking |
| 29 |
behind, i.e. they don't have a current stage3... |
| 30 |
|
| 31 |
|
| 32 |
-- |
| 33 |
Regards, |
| 34 |
Thomas |
Archives