| 1 |
Markus Ullmann wrote: |
| 2 |
|
| 3 |
> Richard Freeman schrieb: |
| 4 |
> |
| 5 |
>> The downside might be division of effort and less unification |
| 6 |
>> (many packages could end up having mutally-exclusive requirements such |
| 7 |
>> as specific package managers that implement particular EAPIs, etc). |
| 8 |
> |
| 9 |
> Plus you have no central place to report bugs and no stable |
| 10 |
> infrastructure to maintain stuff. |
| 11 |
> From my POV, one of our strengths over other distributions is that we |
| 12 |
> can provide it all with one repository in one central place and don't |
| 13 |
> have issues with a sources.list longer than any make.conf you can come |
| 14 |
> up with. |
| 15 |
> |
| 16 |
> Overlays are there (even though they are hacks) for development or other |
| 17 |
> packages that don't find a maintainer for some reason; supporting |
| 18 |
> completely different repos like CPAN and whatnot is desirable as you |
| 19 |
> strip packaging workload. |
| 20 |
> But other than that I think we should keep the one big repo strategy. If |
| 21 |
> others feel different, well they can start right now, no technical |
| 22 |
> reason stops people from doing so anyway. |
| 23 |
> |
| 24 |
++ |
| 25 |
|
| 26 |
It would be nice to have better overlay handling though, in the way Rich |
| 27 |
outlined. ATM the best-visible will be used whichever overlay it comes from |
| 28 |
(ordering only affects the case where more than one overlay has that |
| 29 |
version), which can be an issue when using layman. Being able to override |
| 30 |
that on a category or package basis, or indeed simply saying that if a |
| 31 |
package has been emerged from one overlay, restrict to that overlay, would |
| 32 |
be cool. |
| 33 |
|
| 34 |
It'd make people far more relaxed about using sunrise, imo. |
| 35 |
|
| 36 |
|
| 37 |
-- |
| 38 |
gentoo-project@l.g.o mailing list |
Archives