Re: [gentoo-dev] Improving repoman checking, better idea (add arch.desc file)

[james]

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