So I've been talking to kent\n and the conclusion is that our ideas basically do and achieve the same, with a slightly different approach. (I still like mine better though. :)
However one valid point that came up in discussions is - whether an arch supports stable keywords is a per-arch setting, not a per-profile setting. So we can actually make things much easier (and the transition safer). Proposal No 2: * Leave profiles.desc unmodified * Introduce a new file arch.desc, which contains the "stability status" of an arch; Syntax: 2 columns, # arch status amd64 stable mips testing sh unstable The meaning of the keywords "stable", "testing", "unstable" is the same as in the previous proposal, > "Does this arch support stable keywords, and how should "arch" vs. "~arch" > be treated?" > - "stable": separately check consistency of ~arch and arch tree, both have > to be OK. This is what repoman is doing now, and is the default if the 4th > column is undefined. > - "testing": treat "arch" as "~arch" when requiring consistency, do not > check "arch" alone. Useful if an arch wants to prepare going stable, useful > for arch teams maintaining a pseudo-stable subset for stages. repoman could > have a new command line switch that temporarily upgrades from "testing" to > "stable" (for arch team work). > - "unstable": check "~arch" only, "arch" in an ebuild produces a fatal > repoman error The combination of current profiles.desc and new arch.desc provides the same flexibility as in the previous e-mail. Compatibility and transition: 0) PMS should be amended to allow the additional file. 1) Compatibility: No arch.desc and new system, or arch not listed in arch.desc *Arches* are treated as "stable" by repoman (current behaviour), with profile status according to profiles.desc. Gentoolkit and other tools trying to determine a list of stable arches should fall back to current method of scanning profiles.desc for stable profiles. 2) Compatibility: arch.desc and old system Tools ignore the unknown file (?). Repoman and other tools may emit surplus errors when profiles are checked on arches that are "testing" (they check the consistency of the stable tree alone, which is not OK, since "arch" is supposed to be treated like "~arch"). 3) On introduction of the new column, it will be set to "stable" for all stable arches, "testing" for all arches where "inofficial" stable keywords exist (sh, s390, ...), and "unstable" everywhere else. 4) Arches in "testing" or "unstable" may eventually consider re-introducing stable *profiles* so their deptree in ~arch remains consistent. More opinions, flames, cookies? Cheers, Andreas -- Andreas K. Hüttel [email protected] Gentoo Linux developer (council, perl, libreoffice)
signature.asc
Description: This is a digitally signed message part.
