1 |
* Donnie Berkholz <dberkholz@g.o> schrieb: |
2 |
|
3 |
> A slight tweak that you may have already considered: a single package is |
4 |
> split into multiple packages with a metabuild (named the same as the |
5 |
> original single package) in a newer version -- for example, modularized |
6 |
> X. |
7 |
|
8 |
hmm, let's just thing through this: |
9 |
|
10 |
foo-1.0 (monolithic) is installed. |
11 |
foo-2.0 (spliited) should come in by update, depends on fooA and fooB. |
12 |
Obviously fooA and fooB will conflict with foo-1.0. |
13 |
|
14 |
How does portage actually behave on "merge -u foo" ? |
15 |
|
16 |
IMHO, it would block on foo(A|B) vs. installed foo-1.0, since it handles |
17 |
each package separately. |
18 |
|
19 |
To solve this cleanly (and automatically), we'll end up in an transactional |
20 |
requirement: the whole emerge tree (or at least critical parts of it) run |
21 |
in their own dedicated environment (sysroot) and are committed in an atomic |
22 |
step - merging to the running system happens *only* if everything worked |
23 |
fine (maybe optionally including etc-update ?) and so never leaves the |
24 |
system in inconsistent state if someting goes wrong in the middle of |
25 |
this process. |
26 |
|
27 |
But, ugh, that's perhaps far too much for the current portage approach ;-o |
28 |
(I'm actually doing so with my own "Briegel" build system, which is designed |
29 |
for embedded and crititcal targets) |
30 |
|
31 |
> > I strongly suspect that in many (but not all) cases the package manager |
32 |
> > could be making users' lives a lot easier than it currently is... |
33 |
> |
34 |
> Sounds like a great idea. |
35 |
|
36 |
ACK. At least there should be some mechanism to tell the user why |
37 |
exactly this block happened and suggestions how to solve this |
38 |
(of course, manually written by the ebuild authors). Simply adding |
39 |
some file per conflict to be printed out should be enough, IMHO. |
40 |
Maybe this filename could be added in {} directly behind each |
41 |
invididual dep. |
42 |
|
43 |
For the example above it could look like this: |
44 |
|
45 |
fooA-2.0.ebuild: |
46 |
---- |
47 |
|
48 |
... |
49 |
DEPENDS="!foo<2.0{$FILESDIR}/upgrade-from-1.0.inf" |
50 |
... |
51 |
|
52 |
files/upgrade-from-1.0.inf: |
53 |
---- |
54 |
|
55 |
TYPE: pkg-split, src=foo |
56 |
SPLIT-SRC: foo>=2.0 |
57 |
SPLIT-PARTS: fooA, fooB |
58 |
INFO: By version 2.0, foo has been split into the packages fooA and fooB. |
59 |
INFO: The build process can't run directly, since the new sub packages |
60 |
INFO: conflict with the already installed monolithic version within the |
61 |
INFO: build process. |
62 |
INFO: Removing foo and installing it afresh will solve this conflict. |
63 |
|
64 |
|
65 |
As you see, the "INFO: "-Lines are what's printed out to the user, |
66 |
while the other lines could help portage to solve it automatically |
67 |
(if it has an special logic for this) |
68 |
|
69 |
|
70 |
cu |
71 |
-- |
72 |
--------------------------------------------------------------------- |
73 |
Enrico Weigelt == metux IT service - http://www.metux.de/ |
74 |
--------------------------------------------------------------------- |
75 |
Please visit the OpenSource QM Taskforce: |
76 |
http://wiki.metux.de/public/OpenSource_QM_Taskforce |
77 |
Patches / Fixes for a lot dozens of packages in dozens of versions: |
78 |
http://patches.metux.de/ |
79 |
--------------------------------------------------------------------- |
80 |
-- |
81 |
gentoo-dev@l.g.o mailing list |