| 1 |
On Sun, Jul 21, 2013 at 5:34 PM, Rich Freeman <rich0@g.o> wrote: |
| 2 |
> We're starting to drift off topic here, but I've always felt that this |
| 3 |
> is something that could be improved on. I'm not saying that any of |
| 4 |
> this should just be thrown together, but some of the following might |
| 5 |
> be useful: |
| 6 |
> |
| 7 |
> 1. Overlay dependencies (depends on a particular package from a |
| 8 |
> particular overlay). |
| 9 |
|
| 10 |
In EAPI 5-progress, there's support for atom::repo deps. |
| 11 |
|
| 12 |
> 2. Overlay package.* (accept one version of one package from a |
| 13 |
> particular overlay, mask all packages in an overlay that aren't |
| 14 |
> explicitly unmasked, don't apply package.(un)mask from one overlay to |
| 15 |
> packages in another unless the mask references that overlay |
| 16 |
> specifically, etc). |
| 17 |
|
| 18 |
These things are all supported by portage, through use of atom::repo |
| 19 |
in /etc/portage/package.* (or profile with EAPI 5-progress) and |
| 20 |
repo-level configurations in $repo/profiles/package.* (which only |
| 21 |
apply to packages from that repo). |
| 22 |
|
| 23 |
> 3. Repository priority (paludis handles this fairly well I think) - |
| 24 |
> where you can control which overlays override which other ones. |
| 25 |
|
| 26 |
Portage also supports priority setting in /etc/portage/repos.conf. |
| 27 |
|
| 28 |
> I've never really liked the all-or-nothing design of overlays as they |
| 29 |
> currently stand. |
| 30 |
|
| 31 |
These days, they should be much more flexible than they have been in the past. |
| 32 |
|
| 33 |
> Even simply prioritizing them is a pretty crude |
| 34 |
> approach. It makes them fairly useless for general-purpose |
| 35 |
> distribution of packages. |
| 36 |
> |
| 37 |
> Rich |
| 38 |
> |
Archives