Gentoo Archives: gentoo-portage-dev

From: tvali <qtvali@×××××.com>
To: gentoo-portage-dev@l.g.o
Subject: Re: sync suggestions [was Re: [gentoo-portage-dev] Few things, which imho would make portage better]
Date: Wed, 15 Mar 2006 14:19:08
Message-Id: cea53e3c0603150618n264aff38w@mail.gmail.com
In Reply to: sync suggestions [was Re: [gentoo-portage-dev] Few things, which imho would make portage better] by Brian Harring
1 But if any user-side changes are assumed to be separated?
2
3 I mean if there is a boolean field "user", which is triggered for
4 user-changed tables.
5
6 Or, to be simpler, i use 2 tables in my example.
7
8 Lets assume that user wants to change description of dev-lang/php --
9 so that user has to change "dev-lang/php" in table "user-tree", but
10 leave the same in table "portage-tree" unchanged.
11
12 Of course, current example would make queries into portage-db more
13 complex than they should be, so more optimized version should be found
14 -- but, anyway, there are ways to make things work.
15
16 ----------------------------------------------------------------------------------------
17 Imagine that (i take only ebuild files into consideration here):
18 * Portage tree is kept in SQL base, which contains the following fields:
19 ** Id
20 ** LongName (dev-db/mysql-4.1.14)
21 ** Name (dev-db/mysql)
22 ** ShortName (mysql)
23 ** Slot
24 ** Server -- which server or server group contains that ebuild (if
25 same ebuild is in several server, it should be repeated in SQL). If
26 empty, then this ebuild is created by user
27 ** ServerStatus -- false if deleted from server (only used if UserInfo
28 is not NULL)
29 ** Status -- if false, this row will not be used
30 ** Current -- if this ebuild is what should be installed if emerge
31 mysql is written on this system
32 ** Description
33 ** /.../ -- other fields parsed from ebuild
34 ** ServerInfo -- ebuild file from server
35 ** UserInfo -- user additions to that file
36
37 * Dependency tree
38 ** Will be updated from prev. table
39
40 Now, updates in server should be in the following form:
41 * Id
42 * ServerInfo
43 * Action -- add/delete/update
44
45 All other fields will be parsed out from "Action" in user's computer.
46
47 Any changes to portage tree will be then done via portage commands,
48 not directly to SQL.
49
50 2006/3/15, Brian Harring <ferringb@×××××.com>:
51 > On Tue, Mar 14, 2006 at 03:50:18PM +0200, tvali wrote:
52 > > Another question now is about sync.
53 > >
54 > > I did read somewhere, that this is not good user behavior to sync more
55 > > than once per day. I understand that as if this is a huge download
56 > > even if there is nothing changed.
57 > >
58 > > Isnt it nice idea to have this database just optimized?
59 > >
60 > > I mean (assuming portage using SQL now) -- that would be really simple
61 > > to log every change in portage tree as series of SQL queries, which
62 > > would reproduce this change.
63 >
64 > Pushing the delta (what you're suggesting) is only usable if it can be
65 > guranteed the user hasn't modified their tree at all (thus resulting
66 > in cache db differing from upstreams).
67 >
68 > That right there is the brass tacks of it; You wouldn't be able to
69 > push just the changes, you would have to regenerate the _whole_ db
70 > (slow, >20k inserts assuming only one table).
71 >
72 > Sidenote... please post seperate threads for seperate
73 > ideas/discussions, else it's damn hard to look back and pull the
74 > specific thread were something was discussed.
75 > ~harring
76 >
77 >
78 >
79 >
80
81
82 --
83 tvali
84 (e-mail: "qtvali@×××××.com"; msn: "qtvali@×××××.com";
85 icq: "317-492-912")
86
87 Ühe eesti internetifirma lehel kohtasin tsitaati:
88 If you don't do it excellently, dont do it at all. Because if it's not
89 excellent, it won't be profitable or fun, and if you're not in
90 business for fun or profit, what the hell are you doing here?
91 Robert Townsend
92
93 --
94 gentoo-portage-dev@g.o mailing list