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

[Kent Fredric]

On Sun, 29 Jan 2017 14:08:05 -0500
james <garftd@×××××××.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 )