Gentoo Archives: gentoo-dev

From: Enrico Weigelt <weigelt@×××××.de>
To: gentoo-dev@l.g.o
Subject: Re: [gentoo-dev] What are blocks used for?
Date: Thu, 17 Apr 2008 19:33:13
Message-Id: 20080417193122.GH31409@nibiru.local
In Reply to: Re: [gentoo-dev] What are blocks used for? by Donnie Berkholz
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