| 1 |
On Wed, Jan 7, 2015 at 10:52 AM, William Hubbs <williamh@g.o> wrote: |
| 2 |
> My understanding of p.mask is it is never permanent. Things go in |
| 3 |
> there until they get fixed or eventually removed. |
| 4 |
|
| 5 |
I disagree with this. In my opinion, it is fine to have permanently |
| 6 |
masked packages in some cases. I don't really care what the existing |
| 7 |
documentation says on this; documentation can be updated. |
| 8 |
|
| 9 |
> p.masked packages do not directly benefit from any forms of qa (eclass |
| 10 |
> fixes, etc). |
| 11 |
> |
| 12 |
> I don't think, for example, we test eclass changes to see if they |
| 13 |
> break masked packages. |
| 14 |
> |
| 15 |
> Also, as far as I know, we don't use p.masked packages as a |
| 16 |
> way to keep eclasses in the tree do we -- for example, (I haven't looked |
| 17 |
> at the code), but I'm guessing that a number of these packages use |
| 18 |
> games.eclass which is on the way out. If we say we can't get rid of |
| 19 |
> these packages, we may not be able to get rid of games.eclass. |
| 20 |
|
| 21 |
Agreed. If the ebuild has no hope of working at all, there is no point |
| 22 |
in keeping it in the tree. It should not hold up removal of obsolete |
| 23 |
eclasses. |
| 24 |
|
| 25 |
> It is unlikely as well that masked packages are actively maintained at |
| 26 |
> all, especially those that have been setting in the tree masked for |
| 27 |
> multiple years. You are basically asking that we keep bitrotting broken |
| 28 |
> packages in the tree. |
| 29 |
|
| 30 |
If the package is unmaintained and broken, then it should be removed. |
| 31 |
However, there are cases where the package is usable and has been |
| 32 |
masked for some other reason, security being the obvious example. |
Archives