| 1 |
Donnie Berkholz wrote: |
| 2 |
> On 19:18 Mon 02 Mar , Alistair Bush wrote: |
| 3 |
>> Donnie Berkholz wrote: |
| 4 |
> |
| 5 |
> Could you explain what you see as the important difference that makes |
| 6 |
> package.mask bad and a separate overlay good? |
| 7 |
> |
| 8 |
|
| 9 |
Contributors sometimes have difficulty following standards (hell even |
| 10 |
dev's do). I have little confidence that would also be able to actually |
| 11 |
add packages to package.mask without breaking anything else. |
| 12 |
As an example we had a contributor break the manifests of a dozen or so |
| 13 |
packages because he updated the Copyright header then couldn't get the |
| 14 |
ebuild to manifest. I can imagine someone committing dev-java/ant-core |
| 15 |
to the file. That and there are 325 ebuilds [1] in java-experimental. |
| 16 |
Masking even 1/2 of them separately would be a complete nightmare. |
| 17 |
|
| 18 |
I also note that sunrise doesn't seem to do this either. |
| 19 |
|
| 20 |
Also no ebuilds are ever marked stable, so it should be easy for |
| 21 |
someone to just add an entry in their package.keywords file. |
| 22 |
|
| 23 |
And what is stopping a user from wanting to have their own overlay, that |
| 24 |
uses java-overlay ( or java-experimental or any other overlay ) |
| 25 |
packages. Are we to say that we shouldn't allow tools to have support |
| 26 |
for this. I think that it is a nature progression that if we are to |
| 27 |
allow overlays to extend the portage tree that we should allow overlays |
| 28 |
to extend other overlays. |
| 29 |
|
| 30 |
[1] java-experimental $ find . -iname '*.ebuild' | wc -l |
Archives