FE package database

[Hans de Goede]

Warren Togami wrote:
> Chris Weyl wrote:
>> So here's a couple thoughts -- it would have taken more time to type
>> it out than to show the table relationship in dia, so here goes:
>>
>> http://home.comcast.net/~ckweyl/fedora_package_db.dia
>>
>> And yes, it's just a sketch :)
>>
>> It also comes to mind, do we have actual requirements for what we want
>> this database to be able to do?  e.g. just track packages & owners,
>> include builddeps, etc, etc?
> 
> I'm glad that people are talking about possibilities of how to implement
> this, but we should step back and first think about what are our goals,
> what do we actually want out of this?  I think a package database system
> would eventually encompass all kinds of information, but initially we
> must prioritize implementation of things that we need and dependent data
> structures.
> 
> These below are a few higher priority items that we keep discussing as
> needed in FESCO meetings.
> 
> - per-package per-branch fine grained ownership
> - multiple owners possible
> - package groups, subscription, notification
> - views of packages, change history and associated bugs
> - tracking of MIA owners, auto-nag, timeout, notification
> - tracking of neglected packages, timeout, notification
> - tracking of orphans
> 
> The above would allow things like:
> 
> - Build a package that breaks deps of other things in the distro.  A
> background job detects this, and automatically notifies owners and
> whoever subscribed to watch affected packages.
> - Security team could know at-a-glance what is being neglected and step-in.
> 
> Later we will be able to add things like:
> 
> - All of the other informational metadata that wasn't required by the
> above but would be useful to view and search.  This includes stuff like
> dependencies.
> - ACL access grant and revocation by owners at the package/branch level
> (this will become more important as we move closer to merging Core and
> Extras)
> 

May I add to this list:
- per package rpmlint exception, so that a script can be created which
as part of the build on the buildserver runs rpmlint on the created rpms
and fails the resulting packages if they give any warnings/errors not on
the exception list.

Regards,

Hans