| 1 |
On 28/01/17 20:01, Andreas K. Huettel wrote: |
| 2 |
> So, things are a little bit messy right now. We have "stable arches", "arches |
| 3 |
> that are ~arch only (but occasional stable keywords can pop up and be |
| 4 |
> ignored)", "arches that are ~arch only". In addition, some are always checked |
| 5 |
> with repoman, some only with -d or (hic sunt leones) -e flag. |
| 6 |
> |
| 7 |
> The latter is controlled in profiles/profiles.desc, which designates *profiles*, |
| 8 |
> not arches, as stable, dev, or exp. I *think* long ago "stable" here was |
| 9 |
> supposed to also indicate that an arch is stable, but that connection is |
| 10 |
> obsolete (and better should be). |
| 11 |
> |
| 12 |
> To improve our tree status, below I propose an enhancement for profiles.desc. |
| 13 |
> Compatibility and upgrade are discussed at the end of the mail. |
| 14 |
> |
| 15 |
> Proposal: |
| 16 |
> * Introduce a 4th column in profiles.desc |
| 17 |
> * Cosmetically modify the 3rd column |
| 18 |
> |
| 19 |
> Meaning and values of the 3rd column: |
| 20 |
> "Does repoman check this profile?" |
| 21 |
> - "stable": yes, same as now, becomes legacy value to be deprecated |
| 22 |
> - "always": yes, same as "stable" now |
| 23 |
> - "dev": only with -d |
| 24 |
> - "exp": only with -e |
| 25 |
> |
| 26 |
> Meaning and values of the 4th column: |
| 27 |
> "Does this arch support stable keywords, and how should "arch" vs. "~arch" be |
| 28 |
> treated?" |
| 29 |
> - "stable": separately check consistency of ~arch and arch tree, both have to |
| 30 |
> be OK. This is what repoman is doing now, and is the default if the 4th column |
| 31 |
> is undefined. |
| 32 |
> - "testing": treat "arch" as "~arch" when requiring consistency, do not check |
| 33 |
> "arch" alone. Useful if an arch wants to prepare going stable, useful for arch |
| 34 |
> teams maintaining a pseudo-stable subset for stages. repoman could have a new |
| 35 |
> command line switch that temporarily upgrades from "testing" to "stable" (for |
| 36 |
> arch team work). |
| 37 |
> - "unstable": check "~arch" only, "arch" in an ebuild produces a fatal repoman |
| 38 |
> error |
| 39 |
> |
| 40 |
> Compatibility and transition: |
| 41 |
> |
| 42 |
> 0) Interestingly PMS defines profiles.desc and its fields, but does not say |
| 43 |
> anything how it should be used. This could probably be enhanced with the next |
| 44 |
> PMS version. |
| 45 |
> |
| 46 |
> 1) Compatibility: Old profiles.desc and new system |
| 47 |
> The missing 4th column is treated as "stable", which is current behaviour. |
| 48 |
> |
| 49 |
> 2) Compatibility: New profiles.desc and old system |
| 50 |
> A 4th column leads to an error "wrong format" in repoman. This is not so nice, |
| 51 |
> but a pure developer problem (and these can be expected to update repoman). |
| 52 |
> Also gentoolkit displays a backtrace. |
| 53 |
> Testing shows no impact on "emerge" (portage team plz confirm), meaning that |
| 54 |
> broken utilities (repoman, gentoolkit) can be updated to working versions |
| 55 |
> normally. |
| 56 |
> |
| 57 |
> 3) On introduction of the new column, it can be left empty for the moment. |
| 58 |
> Arches like e.g. mips could eventally move from "dev stable" to "always |
| 59 |
> testing" or "always unstable" to maintain a consistent ~arch deptree and maybe |
| 60 |
> upgrade to stable some day. |
| 61 |
> |
| 62 |
> |
| 63 |
> Opinions, flames, cookies? |
| 64 |
> |
| 65 |
> Cheers, Andreas |
| 66 |
> |
| 67 |
> |
| 68 |
Andreas, et al, |
| 69 |
|
| 70 |
How does this compare/contrast/integrate with kent\n's proposal |
| 71 |
regarding "profiles.types"? It looks complementary at worst, possibly |
| 72 |
much the same at best. Since you're in relatively close contact, perhaps |
| 73 |
you could discuss and present a joint effort with possibly plural |
| 74 |
schemes? Just my observations! :) |
| 75 |
|
| 76 |
Cheers, |
| 77 |
MJE |
Archives