On 01/29/2017 10:06 AM, Andreas K. Huettel wrote:
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
I like what I have read here and elsewhere.
Solutions centric around a minimized profile will allow gentooers to
use identical (minimized) profiles for a wide variety of hardware
types:: different uP, dsp, fpga, custom (soc, asic, etc). I.E.
heterogeneous gentoo clusters without any systemd associated codes. I do
not have access to Kent's posting so perhaps a reference to Kent's ideas?
It would be very much appreciated if there is a posting on this list of
what the consensus becomes, with some discussion as to how it will
affect the ever expanding variety of cluster formations, particularly
gentoo-style unikernel types of clusters and how to cluster up a variety
of gentoo-embedded systems, which are actually quite similar to
unikernel based clusters.
A state-diagram of just how all of these profiles are intertwined, would
help to clarify the details and thus be keenly appreciate, when a final
verdict is reached.
hth,
James
