| 1 |
On Sat, Aug 06, 2011 at 04:13:52PM +0200, Fabian Groffen wrote: |
| 2 |
> - tree generation is dynamic |
| 3 |
> + easy to move packages around, their category is specified by the |
| 4 |
> tree configuration, the repository the package lives in doesn't change, |
| 5 |
> probably overlays, betagarden, graveyard, sunset, etc. can all go |
| 6 |
> - per package branches |
| 7 |
> + instead of developing in overlays, simply branches could be used, |
| 8 |
> such that a single place is sufficient to for each package |
| 9 |
|
| 10 |
Recreating the overlay experience with many repos sounds |
| 11 |
difficult. Many overlays include multi-component packages or changes |
| 12 |
to interdependent packages. Using per-package branching instead of |
| 13 |
overlays would complicate this, with a user (or layman) having to |
| 14 |
search each package's repository for branches associated with a |
| 15 |
particular overlay when trying to guess which overlay a package should |
| 16 |
be pulled from. |
| 17 |
|
| 18 |
The current behavior of PORTDIR_OVERLAY is quite well-defined and |
| 19 |
easier to understand. It even allows overlays to gracefully fall |
| 20 |
behind in keeping their packages up to date. For example, when a fix |
| 21 |
in an overlay is committed to gentoo-x86 as a new ebuild revision, the |
| 22 |
overlay maintainer can forget that he has a stale version of the |
| 23 |
package without harming anyone because portage chooses the newest |
| 24 |
package. It seems that the traditional overlay idea -- where overlays |
| 25 |
overlay gentoo-x86 and eachother -- can't quite exist with per-package |
| 26 |
branches. To recreate this idea, you'd need to have one checkout per |
| 27 |
package per repo (including overlays) and you'd still use |
| 28 |
PORTDIR_OVERLAY. |
| 29 |
|
| 30 |
I sorta like how overlays work currently ;-). |
| 31 |
|
| 32 |
-- |
| 33 |
binki |
| 34 |
|
| 35 |
Look out for missing or extraneous apostrophes! |
Archives