1 |
On Thursday 28 of January 2010 00:58:59 Oswald Buddenhagen wrote: |
2 |
> On Wed, Jan 27, 2010 at 10:46:52PM +0100, Thiago Macieira wrote: |
3 |
> > [...] The build rules are: [...] |
4 |
> |
5 |
> why not (mostly) keep our current layout in form of a meta structure (be |
6 |
> it git submodules or not)? build order would be determined by cmakelists |
7 |
> which declare subdirectories (and *nothing* else) as ever. breaking out |
8 |
> of that layout would happen at own peril, but any breakage will be |
9 |
> quickly detected anyway (as the projects' cmakelists must be |
10 |
> self-contained and dependency-complete). |
11 |
> |
12 |
> On Wed, Jan 27, 2010 at 10:56:21PM +0100, Thiago Macieira wrote: |
13 |
> > And here's a suggestion to address those points, so a modification to the |
14 |
> > rules in the earlier email. |
15 |
> > |
16 |
> > Instead of having 4 stages per category, we actually have: |
17 |
> > libs |
18 |
> > libs2 |
19 |
> > libs3 |
20 |
> > ... |
21 |
> |
22 |
> you know, sysvinit is now moving away from fixed priorities to a |
23 |
> dependency-based system ... ;) |
24 |
> anyway, my private build script does effectively the same, so it isn't |
25 |
> that bad as such. :D |
26 |
|
27 |
I'll drop in some comments here as in Gentoo we run into similar problems when |
28 |
trying to migrate to git (we did not do it yet, details follows). |
29 |
|
30 |
Mentioned atomicity |
31 |
|
32 |
This is actually what (I think - unfortunately) caused that our package |
33 |
repository is not going to be split into subprojects (like KDE, GNOME, |
34 |
WebApps, Java, and such). Our repository is in following format: |
35 |
category1/package1/package1-version.ebuild (along with some other files) |
36 |
category2/package2/package2-version.ebuild |
37 |
... |
38 |
profiles/<subprofile> (along with many other files) |
39 |
|
40 |
(skip to "Git dependencies" if you don't care) |
41 |
There are inter-dependencies (also mutual - like for instance blocks) between |
42 |
packages, and what's the most important - profiles/ subdirectory contains |
43 |
repository-wide settings, so the simplest approach is to provide atomicity by |
44 |
keeping all in one repository. |
45 |
It's all fine with this, but one problem - purely technical - repository is |
46 |
huge enough (not as big as KDE one though) to make cloning it directly |
47 |
impractical as repacking on server side will simply kill the server (thus |
48 |
clones has to be delivered in alternative way - like git bundles or via rsync |
49 |
- and direct cloning explicitly disabled on server by the means of patching |
50 |
git). |
51 |
This is what actually holds our migration as splitting repository would need |
52 |
extensive changes to our package manager - repository dependencies, making |
53 |
profiles/ local to repository, and creating for instance master repository |
54 |
holding only profiles/ - global settings - and adding it as dependency for any |
55 |
other. |
56 |
|
57 |
Git "dependencies" |
58 |
|
59 |
This is quite similar to what you're trying to achieve with KDE - as you need |
60 |
to have some means to 'fake' git repository dependencies - either by the |
61 |
meaning "exactly this version of kdelibs.git" or more likely - "version of |
62 |
kdelibs.git at least". |
63 |
|
64 |
To be frank I don't exactly understand how would you achieve it automatically |
65 |
- manually - it would need to create some metadata file in toplevel directory |
66 |
of particular git repository for instance with following format (here as bash |
67 |
array but that's just example - file metadata toplevel repo dir): |
68 |
|
69 |
need=( |
70 |
<path_to_repo>:<branch>[:<commit>] |
71 |
... |
72 |
) |
73 |
|
74 |
Where <path_to_repo> would be relative path to particular repository - for |
75 |
instance 'kdelibs.git' or 'kdegames/libkdegames.git', <branch> being the name |
76 |
of the branch ("4.4", "master" etc) and optional <commit> would be any name |
77 |
that git understands as a commit identifier - so tag, sha1. For correctness |
78 |
branch 'tip' names (like 'master') should probably be forbidden. |
79 |
|
80 |
I really don't think there's need to invent new layout - your module layout on |
81 |
server is quite nice already (maybe just add 'playground' and review |
82 |
'subdirectories' there like Thiago proposed_, so (layout on server) : |
83 |
cmakemodules.git (read below) |
84 |
kdelibs.git |
85 |
kdegames/ |
86 |
libkdegames.git |
87 |
kpat.git |
88 |
review/ |
89 |
somnewshinygame.git |
90 |
playground/ |
91 |
somebleedingedgegame.git |
92 |
|
93 |
Of course git itself doesn't understand any dependencies so you'd need to |
94 |
provide some scripts to clone repository AND recursively its dependencies |
95 |
(along with local hooks maybe to update those dependencies to match |
96 |
requirements in metadata - also this metadata would need to be updated |
97 |
manually when needed (for all remote branches independently). |
98 |
|
99 |
CMake modules |
100 |
|
101 |
I'd propose separate repository for them and adding it as a dependency of all |
102 |
other repositories that need it (also with version specifier) - it would |
103 |
prevent .cmake modules duplication. Update/clone script would need to clone |
104 |
this cmake modules repo to known local location (actually locations of all |
105 |
local clones need to be well defined if one is to include_directories from |
106 |
them for instance), so that all other projects (repositories) would just add |
107 |
in first line of CMakeLists.txt: |
108 |
|
109 |
set (CMAKE_MODULE_PATH "${CMAKE_CURRENT_SOURCE_DIR}/../cmakemodules/") |
110 |
|
111 |
All this still need writing script to recursively create tags, tarballs |
112 |
(there's still possibility to package it the way it is now - as modules), |
113 |
recursively update dependencies (for instance working) or just update |
114 |
dependencies. |
115 |
|
116 |
As for work flow |
117 |
|
118 |
I think Thiago is on the spot that it's much safer to work on stable branch |
119 |
and forward-port bugfixes instead. Personally - there was very few of them - |
120 |
but it happened that I needed to reopen KDE bug marked as RESOLVED/FIXED just |
121 |
after fix has been commited to stable branch. |
122 |
|
123 |
My .5 |
124 |
|
125 |
-- |
126 |
regards |
127 |
MM |