[gentoo-dev] Improving profiles/profiles.desc and repoman checking

[gentoo-dev] Improving profiles/profiles.desc and repoman checking

[Andreas K. Huettel]

[-- Attachment #1: Type: text/plain, Size: 2949 bytes --]

So, things are a little bit messy right now. We have "stable arches", "arches 
that are ~arch only (but occasional stable keywords can pop up and be 
ignored)", "arches that are ~arch only". In addition, some are always checked 
with repoman, some only with -d or (hic sunt leones) -e flag. 

The latter is controlled in profiles/profiles.desc, which designates *profiles*, 
not arches, as stable, dev, or exp. I *think* long ago "stable" here was 
supposed to also indicate that an arch is stable, but that connection is 
obsolete (and better should be). 

To improve our tree status, below I propose an enhancement for profiles.desc. 
Compatibility and upgrade are discussed at the end of the mail. 

Proposal: 
* Introduce a 4th column in profiles.desc
* Cosmetically modify the 3rd column

Meaning and values of the 3rd column:
"Does repoman check this profile?"
- "stable": yes, same as now, becomes legacy value to be deprecated
- "always": yes, same as "stable" now
- "dev": only with -d
- "exp": only with -e

Meaning and values of the 4th column:
"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

Compatibility and transition: 

0) Interestingly PMS defines profiles.desc and its fields, but does not say 
anything how it should be used. This could probably be enhanced with the next 
PMS version. 

1) Compatibility: Old profiles.desc and new system
The missing 4th column is treated as "stable", which is current behaviour. 

2) Compatibility: New profiles.desc and old system
A 4th column leads to an error "wrong format" in repoman. This is not so nice, 
but a pure developer problem (and these can be expected to update repoman). 
Also gentoolkit displays a backtrace.
Testing shows no impact on "emerge" (portage team plz confirm), meaning that 
broken utilities (repoman, gentoolkit) can be updated to working versions 
normally.

3) On introduction of the new column, it can be left empty for the moment. 
Arches like e.g. mips could eventally move from "dev stable" to "always 
testing" or "always unstable" to maintain a consistent ~arch deptree and maybe 
upgrade to stable some day.


Opinions, flames, cookies?

Cheers, Andreas


-- 
Andreas K. Hüttel
dilfridge@gentoo.org
Gentoo Linux developer (council, perl, libreoffice)

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 981 bytes --]

Re: [gentoo-dev] Improving profiles/profiles.desc and repoman checking

[M. J. Everitt]

[-- Attachment #1.1: Type: text/plain, Size: 3364 bytes --]

On 28/01/17 20:01, Andreas K. Huettel wrote:
> So, things are a little bit messy right now. We have "stable arches", "arches 
> that are ~arch only (but occasional stable keywords can pop up and be 
> ignored)", "arches that are ~arch only". In addition, some are always checked 
> with repoman, some only with -d or (hic sunt leones) -e flag. 
>
> The latter is controlled in profiles/profiles.desc, which designates *profiles*, 
> not arches, as stable, dev, or exp. I *think* long ago "stable" here was 
> supposed to also indicate that an arch is stable, but that connection is 
> obsolete (and better should be). 
>
> To improve our tree status, below I propose an enhancement for profiles.desc. 
> Compatibility and upgrade are discussed at the end of the mail. 
>
> Proposal: 
> * Introduce a 4th column in profiles.desc
> * Cosmetically modify the 3rd column
>
> Meaning and values of the 3rd column:
> "Does repoman check this profile?"
> - "stable": yes, same as now, becomes legacy value to be deprecated
> - "always": yes, same as "stable" now
> - "dev": only with -d
> - "exp": only with -e
>
> Meaning and values of the 4th column:
> "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
>
> Compatibility and transition: 
>
> 0) Interestingly PMS defines profiles.desc and its fields, but does not say 
> anything how it should be used. This could probably be enhanced with the next 
> PMS version. 
>
> 1) Compatibility: Old profiles.desc and new system
> The missing 4th column is treated as "stable", which is current behaviour. 
>
> 2) Compatibility: New profiles.desc and old system
> A 4th column leads to an error "wrong format" in repoman. This is not so nice, 
> but a pure developer problem (and these can be expected to update repoman). 
> Also gentoolkit displays a backtrace.
> Testing shows no impact on "emerge" (portage team plz confirm), meaning that 
> broken utilities (repoman, gentoolkit) can be updated to working versions 
> normally.
>
> 3) On introduction of the new column, it can be left empty for the moment. 
> Arches like e.g. mips could eventally move from "dev stable" to "always 
> testing" or "always unstable" to maintain a consistent ~arch deptree and maybe 
> upgrade to stable some day.
>
>
> Opinions, flames, cookies?
>
> Cheers, Andreas
>
>
Andreas, et al,

How does this compare/contrast/integrate with kent\n's proposal
regarding "profiles.types"? It looks complementary at worst, possibly
much the same at best. Since you're in relatively close contact, perhaps
you could discuss and present a joint effort with possibly plural
schemes? Just my observations! :)

Cheers,
MJE


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [gentoo-dev] Improving profiles/profiles.desc and repoman checking

[Andreas K. Huettel]

[-- Attachment #1: Type: text/plain, Size: 431 bytes --]

Am Samstag, 28. Januar 2017, 20:32:54 CET schrieb M. J. Everitt:
>
> How does this compare/contrast/integrate with kent\n's proposal
> regarding "profiles.types"?

Oops. 

Sorry I'm a bit back in mailing list reading. I came up with this some time 
ago, and wanted to finally send it out. Will read the backlog now... :/


-- 
Andreas K. Hüttel
dilfridge@gentoo.org
Gentoo Linux developer (council, perl, libreoffice)

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 981 bytes --]

Re: [gentoo-dev] Improving profiles/profiles.desc and repoman checking

[M. J. Everitt]

[-- Attachment #1.1: Type: text/plain, Size: 499 bytes --]

On 28/01/17 20:38, Andreas K. Huettel wrote:
> Am Samstag, 28. Januar 2017, 20:32:54 CET schrieb M. J. Everitt:
>> How does this compare/contrast/integrate with kent\n's proposal
>> regarding "profiles.types"?
> Oops. 
>
> Sorry I'm a bit back in mailing list reading. I came up with this some time 
> ago, and wanted to finally send it out. Will read the backlog now... :/
>
>
As noted in IRC, and apologies to ML readers .. this was a post kent
made in IRC .. not on the ML!!

MJE


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

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

[Andreas K. Huettel]

[-- Attachment #1: Type: text/plain, Size: 2837 bytes --]

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
dilfridge@gentoo.org
Gentoo Linux developer (council, perl, libreoffice)

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

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

[Mart Raudsepp]

Ühel kenal päeval, P, 29.01.2017 kell 16:06, kirjutas Andreas K.
Huettel:
> 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, 

Maybe declare from the start that any extra columns should be silently
ignored in implementations from start, as to be able to safely add more
columns in the future without breaking backwards compatibility.

> > "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. 

Might want a "broken" (with maybe a better name) for some of these. I
bet the ~arch of some of these is broken too, and no-one to respond to
keyword requests, just happens when it happens.
arm64 and mips are in that state too until we get that fixed and could
move to "testing" and then later "stable" in case of arm64.

> 4) Arches in "testing" or "unstable" may eventually consider re-
> introducing 
> stable *profiles* so their deptree in ~arch remains consistent.

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

[Kent Fredric]

[-- Attachment #1: Type: text/plain, Size: 999 bytes --]

On Sun, 29 Jan 2017 18:20:34 +0200
Mart Raudsepp <leio@gentoo.org> wrote:

> Maybe declare from the start that any extra columns should be silently
> ignored in implementations from start, as to be able to safely add more
> columns in the future without breaking backwards compatibility.

Maybe not silently, maybe just a warning that there are additional columns
or field values not supported by the existing version, so that one knows
they are possibly missing out on some important checks.

Maybe even worth specifying that the first line of the file is a comment
like

# version:app-portage/repoman-2.3.1

Which can be extracted and displayed to a user as follows:

"Unsupported values in profiles/arch.desc: foo, bar, baz
 Consider upgrading to at least ${version} or equivalent"

Where "${version}" is extracted via /#\s*version:([^ ]*)/

( That is, showing the contents of the part after "version:" verbatim
  and not even considering doing version comparisons )



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

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

[Kent Fredric]

[-- Attachment #1: Type: text/plain, Size: 1637 bytes --]

On Sun, 29 Jan 2017 18:20:34 +0200
Mart Raudsepp <leio@gentoo.org> wrote:

> Might want a "broken" (with maybe a better name) for some of these. I
> bet the ~arch of some of these is broken too, and no-one to respond to
> keyword requests, just happens when it happens.
> arm64 and mips are in that state too until we get that fixed and could
> move to "testing" and then later "stable" in case of arm64.

This is one aspect I liked about my other proposal, that the behaviours
associated with various keywords was well defined.

---
# keywords: 
#   - strict: arch-foo and ~arch-foo treated distinctly
#   - mixed: arch-foo treated as ~arch-foo
#   - any: packages that exist and have any keywords are ~arch-foo
#
# dependencies:
#   - enforce: referential integrity within logical keywords 
#              is required
#   - warn: referential integrity within logical keywords
#           warns when its bad, and enforced with -d
#   - ignore: referential integrity is not even considered
#             without -e y  and enforced with -e y

# name  | keywords | dependencies
stable strict check

# was strict ignore
dev mixed warn
exp mixed ignore
----

In that, its instructive as to the significance of the terms.

"Unstable" and "Broken" don't really say much to me.

But dependencies=ignore much more adequately communicates to me
the state that, dependency coherence is known to be problematic
and that you should not care about dependency coherence unless
you have some specific agenda.


If we can mix and match some of these designs with the arch.desc file
however, I'm all for it.

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

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

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

[Kent Fredric]

[-- Attachment #1: Type: text/plain, Size: 4097 bytes --]

On Sun, 29 Jan 2017 14:08:05 -0500
james <garftd@verizon.net> wrote:

>  I do 
> not have access to Kent's posting so perhaps a reference to Kent's ideas?

Happened on IRC, not on any ML ( though I copied a basic copy of it in another thread )

But I'm not going to reiterate it here due to its chances of introducing confusion.

To an extent there are things I like about the arches.desc proposal, but there are
things I'd avoid.

For instance:

---
  amd64  stable
---

In arches.desc doesn't really improve the situation a whole lot over the current situation
where the equivalent data in profiles.desc is itself, lacking sufficient granularity.

Instead, I'd rather the <arches.desc> file contain columns describing specific treatment of
specific things.

So instead, I'd prefer something in <arches.desc> akin to ( but not necessarily identical to )

---
   amd64 keywords=strict checkdeps=stable enforcedeps=stable
   mips  keywords=mixed  checkdeps=stable enforcedeps=dev
   m68k  keywords=mixed  checkdeps=exp    enforcedeps=exp
---

Now, I've used a "<key>=<value>" syntax here inline mostly because it makes examples easier
to show briefly, but a column-oriented syntax as "arch,keywords,checkdeps,enforcedeps" would also be fine.

I'd imagine the legal values for "keywords" being as follows:

- strict: arch-foo and ~arch-foo treated distinctly
- mixed: arch-foo treated as ~arch-foo
- any: packages that exist and have any keywords are ~arch-foo


"checkdeps" and "enforcedeps" are controls that dictate how to handle this arch
by default in repoman, all accepting the terms "stable, dev, exp, never"

- checkdeps=stable : dependency consistency is checked and reported by default
- checkdeps=dev    : dependency consistency is only checked and reported with -d or -e y
- checkdeps=exp    : dependency consistency is only checked and reported with -e y

- enforcedeps=stable : dependency consistency failures are fatalised by default
- enforcedeps=dev    : dependency consistency failures are only fatalized with -d or -e y
- enforcedeps=exp    : dependency consistency failures are only fatailised with -e y

However, in writing this, I realised that some profiles we may have in future may be inherently *archless*
and I don't know how this approach will work in conjunction with that.

Which draws me back to my original idea of having "profiles.types", where field[1] is a freeform value
which is used as field[3] in profiles.desc

Here is what a "profiles.types" would look like today:

---
   stable keywords=strict checkdeps=stable enforcedeps=stable
   dev    keywords=strict checkdeps=dev    enforcedeps=dev
   exp    keywords=strict checkdeps=exp    enforcedeps=exp
---

And here is how we want it to look in the near future

---
   stable keywords=strict checkdeps=stable enforcedeps=stable
   dev    keywords=mixed  checkdeps=stable enforcedeps=dev
   exp    keywords=mixed  checkdeps=exp    enforcedeps=exp
---

And down the road, we may want to add a third grade, "testing"

---
   stable  keywords=strict checkdeps=stable enforcedeps=stable
   testing keywords=strict checkdeps=stable enforcedeps=dev
   dev     keywords=mixed  checkdeps=stable enforcedeps=dev
   exp     keywords=mixed  checkdeps=exp    enforcedeps=exp
---

Even later down the road we could add an argument "-t" to repoman
which would allow us to add another field to the list:

- checkdeps=testing   : dependency consistency is checked  with -t, -d, or -e y
- enforcedeps=testing : dependency consistency is enforced with -t, -d, or -e y

---
   stable  keywords=strict checkdeps=stable enforcedeps=stable
   testing keywords=strict checkdeps=stable enforcedeps=testing
   dev     keywords=mixed  checkdeps=stable enforcedeps=dev
   exp     keywords=mixed  checkdeps=exp    enforcedeps=exp
---

But like, I'm not really sure enough about what I want to write a full proposal
for anything yet, ( Though I am getting really fond of <key>=<value> instead of
relying on columns to identify key )




[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

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

[Andreas K. Huettel]

[-- Attachment #1: Type: text/plain, Size: 763 bytes --]

Am Montag, 30. Januar 2017, 09:29:06 CET schrieb Kent Fredric:

> ---
>    amd64 keywords=strict checkdeps=stable enforcedeps=stable
>    mips  keywords=mixed  checkdeps=stable enforcedeps=dev
>    m68k  keywords=mixed  checkdeps=exp    enforcedeps=exp
> ---

The problem with this is that (already now) dependency checking and enforcing 
is done per profile. And (as we've seen in a separate thread) via mask and 
force files the deptree can look quite different. 

So this would have to apply to *all* profiles of an arch, with a loss of 
functionality. And with a loss of speed, there's a good reason why on arm e.g. 
only one profile is stable.

-- 
Andreas K. Hüttel
dilfridge@gentoo.org
Gentoo Linux developer (council, perl, libreoffice)

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 981 bytes --]

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

[Andreas K. Huettel]

[-- Attachment #1: Type: text/plain, Size: 2101 bytes --]

> > 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, 
> 
> Maybe declare from the start that any extra columns should be silently
> ignored in implementations from start, as to be able to safely add more
> columns in the future without breaking backwards compatibility.

Makes sense.

> > 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. 
> 
> Might want a "broken" (with maybe a better name) for some of these. I
> bet the ~arch of some of these is broken too, and no-one to respond to
> keyword requests, just happens when it happens.
> arm64 and mips are in that state too until we get that fixed and could
> move to "testing" and then later "stable" in case of arm64.

That's already "in the system". Let's discuss, for example, m68k (my favourite 
broken arch). 

Now: 
* There are some stable keywords hanging around, but nobody cares about them 
except the m68k arch team (= Mike).
* All m68k profiles are "exp".
Repoman happily ignores it (unless you use -e).

In the near future:
* m68k is marked "testing" in arches.desc
* All m68k profiles remain "exp"
Repoman *still* happily ignores it (unless you use -e); if you use -e, it will 
test it with ~m68k=m68k.

In the far future, given the arch team is intersted:
* Upgrade profiles from exp to dev or even stable -> repoman will test it more, 
but still using ~m68k=m68k. 

So, whatever "non-support for broken arches" we have now will keep existing. 
Just that migrating away from it gets easier.

-- 
Andreas K. Hüttel
dilfridge@gentoo.org
Gentoo Linux developer (council, perl, libreoffice)

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 981 bytes --]