On Thu, Jul 13, 2017 at 09:11:42AM +0100, Richard W.M. Jones wrote:
> On Tue, Jul 11, 2017 at 06:53:40AM -0700, stan wrote:
> > On Tue, 11 Jul 2017 13:52:32 +0200
> > Michael Schroeder <mls@xxxxxxx> wrote:
> >
> > > So, suggesting different databases is fine and all, but they have
> > > to be integrated and well tested. We re-added support for multiple
> > > database just for that, so that we can test things and decide what
> > > to do.
> >
> > Does this mean it would be possible to add support for a real
> > database as an option? Like postgresql or mariahdb or mysql? That
> > would give access to views, triggers, and stored procedures. Then when
> > an rpm update occurred, the views of what it depends on and what
> > depends on it could be updated by a stored procedure triggered by the
> > update. This would also simplify, and speed, dnf since it could just
> > run a sql query to find all dependencies and their versions (I think).
> > And real databases allow granular access to be defined for users per
> > table. Heavy weight solution, but some benefits.
>
> You'd be able to do most of this if sqlite was used as the default
> backend.
That wouldn't speed up dnf in any way, though. Dnf uses a sat solver
for solving, it works by translating all dependencies into package
rules and then running the sat algorithm on the rules.
This translation needs to be done for all installed packages, so it
always has to read them all. A Query mechanism is thus not needed
at all.
Dnf itself only reads installed packages that are new, it uses a
cache for the ones it already knows about (the @System.solv file
for the curious).
Cheers,
Michael.
--
Michael Schroeder mls@xxxxxxx
SUSE LINUX GmbH, GF Jeff Hawn, HRB 16746 AG Nuernberg
main(_){while(_=~getchar())putchar(~_-1/(~(_|32)/13*2-11)*13);}
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
