[prev in list] [next in list] [prev in thread] [next in thread] 

List:       gentoo-dev
Subject:    Re: [gentoo-dev] Keywordreqs and slacking arch teams
From:       A Schenck <lane_andrew () hotmail ! com>
Date:       2019-12-30 1:45:00
Message-ID: MN2PR17MB39831231A64114C7CA6134469D270 () MN2PR17MB3983 ! namprd17 ! prod ! outlook ! com
[Download RAW message or body]

On 12/28/19 3:14 AM, Michael 'veremitz' Everitt wrote:
> On 28/12/19 11:05, Kent Fredric wrote:
>> On Sat, 28 Dec 2019 10:35:09 +0100
>> Fabian Groffen <grobian@gentoo.org> wrote:
>>
>>> Hmmm, interested to hear what kind of things you're thinking about here.
>> A lot of the "Work" of filing a keyword request is modelling all the
>> consequential keywordings that have to take place.
>>
>> If there was say, a web based UI, that:
>>
>> - Automatically determined which packages are ready for stabilization
>>   due to all their dependencies already being stable (and maybe with
>>   automatic cooldown-from-testing detection )
>>
>> - Automatically determined which packages can be keyworded without
>>   additional work due to all their dependencies being keyworded
> <snip>
>
> I know I'm gonna be shot down in flames, because $heresy, but here is where
> a package 'database' would actually work quite well, because you can
> trivially create a query that pulls this data out, and sorts it by package
> category or maintainer or whatever you like ..
app-portage/kuroo manages an SQLite database of packages without any
bash sourcing craziness, but defers to `emerge` to do the actual install
/ uninstall work and parses stdout and stderr from it.  DB schema is
described at
https://sourceforge.net/p/kuroo/code/HEAD/tree/kuroo4/trunk/src/core/portagedb.cpp#l219
and there are queries for packages by category / subcategory, installed
/ updateable status, and search string there.  Code to walk the main
tree from md5-cache and fill in those tables starts about
https://sourceforge.net/p/kuroo/code/HEAD/tree/kuroo4/trunk/src/core/scanportagejob.cpp#l135
.  Back before burnout there was some hope of porting it to a 'unified
portage API' that dol-sen wanted to build for other portage tools to
use, but that never came to fruition.  Most of this code is 15 years old
though, and I've only done the bare minimum to keep it working-ish as
portage and the tree have changed.
>
> Ok, let the flamewars begin ...
>

-A


[prev in list] [next in list] [prev in thread] [next in thread]