| 1 |
On Sun, Jul 21, 2013 at 6:33 PM, Michał Górny <mgorny@g.o> wrote: |
| 2 |
> Dnia 2013-07-22, o godz. 00:16:31 |
| 3 |
> hasufell <hasufell@g.o> napisał(a): |
| 4 |
>> - users have to run "layman -a foo" ...I hope they will manage (and the |
| 5 |
>> masking reason will be updated to explain where to look for googleearth |
| 6 |
>> ebuilds) |
| 7 |
> |
| 8 |
> Then to get *a single package* they start using the whole overlay. If |
| 9 |
> it's a sane overlay, fine. But some overlays really replace a lot of |
| 10 |
> stuff silently and trigger failures we didn't even imagine before. |
| 11 |
> |
| 12 |
|
| 13 |
We're starting to drift off topic here, but I've always felt that this |
| 14 |
is something that could be improved on. I'm not saying that any of |
| 15 |
this should just be thrown together, but some of the following might |
| 16 |
be useful: |
| 17 |
|
| 18 |
1. Overlay dependencies (depends on a particular package from a |
| 19 |
particular overlay). |
| 20 |
2. Overlay package.* (accept one version of one package from a |
| 21 |
particular overlay, mask all packages in an overlay that aren't |
| 22 |
explicitly unmasked, don't apply package.(un)mask from one overlay to |
| 23 |
packages in another unless the mask references that overlay |
| 24 |
specifically, etc). |
| 25 |
3. Repository priority (paludis handles this fairly well I think) - |
| 26 |
where you can control which overlays override which other ones. |
| 27 |
|
| 28 |
I've never really liked the all-or-nothing design of overlays as they |
| 29 |
currently stand. Even simply prioritizing them is a pretty crude |
| 30 |
approach. It makes them fairly useless for general-purpose |
| 31 |
distribution of packages. |
| 32 |
|
| 33 |
Rich |
Archives