On Sun, 29 Jan 2017 14:08:05 -0500 james <[email protected]> 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 )
pgp30z1qRmt2l.pgp
Description: OpenPGP digital signature
