| 1 |
On Sun, Mar 12, 2017 at 02:54:22PM -0400, Rich Freeman wrote: |
| 2 |
> On Sun, Mar 12, 2017 at 2:45 PM, Kristian Fiskerstrand <k_f@g.o> wrote: |
| 3 |
> > |
| 4 |
> > In most cases lack of maintainer participation is likely the issue to |
| 5 |
> > begin with. The primary issue with a package mask of this nature is that |
| 6 |
> > it is more permanent than temporary in nature. To what extent would |
| 7 |
> > other package maintainers need to take it into consideration e.g wrt |
| 8 |
> > depgraph breakages (say this is a lower slotted version or last version |
| 9 |
> > that supports a specific arch). |
| 10 |
> > |
| 11 |
> > Granted that isn't much of an issue from the security point of view, but |
| 12 |
> > goes more over on QA. |
| 13 |
> |
| 14 |
> Sure, and if a package like this becomes a blocker then that would be |
| 15 |
> a reason to remove it. |
| 16 |
> |
| 17 |
> The fact that it has a security issue is actually irrelevant to that decision. |
| 18 |
|
| 19 |
I disagree with this argument. A security issue *is* a problem, |
| 20 |
especially if we are masking the package because of the security issue. |
| 21 |
|
| 22 |
imo to increase the quality of the tree, packages with known, unfixable |
| 23 |
security issues belong in overlays, not in the main tree. |
| 24 |
|
| 25 |
William |
Archives