* Donnie Berkholz <dberkholz@g.o> schrieb:

> A slight tweak that you may have already considered: a single package is 
> split into multiple packages with a metabuild (named the same as the 
> original single package) in a newer version -- for example, modularized 
> X.

hmm, let's just thing through this:

foo-1.0 (monolithic) is installed.
foo-2.0 (spliited) should come in by update, depends on fooA and fooB.
Obviously fooA and fooB will conflict with foo-1.0.

How does portage actually behave on "merge -u foo" ?

IMHO, it would block on foo(A|B) vs. installed foo-1.0, since it handles
each package separately. 

To solve this cleanly (and automatically), we'll end up in an transactional 
requirement: the whole emerge tree (or at least critical parts of it) run 
in their own dedicated environment (sysroot) and are committed in an atomic 
step - merging to the running system happens *only* if everything worked 
fine (maybe optionally including etc-update ?) and so never leaves the 
system in inconsistent state if someting goes wrong in the middle of 
this process.

But, ugh, that's perhaps far too much for the current portage approach ;-o
(I'm actually doing so with my own "Briegel" build system, which is designed
for embedded and crititcal targets)

> > I strongly suspect that in many (but not all) cases the package manager
> > could be making users' lives a lot easier than it currently is...
> 
> Sounds like a great idea.

ACK. At least there should be some mechanism to tell the user why
exactly this block happened and suggestions how to solve this
(of course, manually written by the ebuild authors). Simply adding
some file per conflict to be printed out should be enough, IMHO.
Maybe this filename could be added in {} directly behind each
invididual dep.

For the example above it could look like this:

fooA-2.0.ebuild:
----

...
DEPENDS="!foo<2.0{$FILESDIR}/upgrade-from-1.0.inf"
...

files/upgrade-from-1.0.inf:
----

TYPE: pkg-split, src=foo
SPLIT-SRC: foo>=2.0
SPLIT-PARTS: fooA, fooB  
INFO: By version 2.0, foo has been split into the packages fooA and fooB.
INFO: The build process can't run directly, since the new sub packages 
INFO: conflict with the already installed monolithic version within the 
INFO: build process. 
INFO: Removing foo and installing it afresh will solve this conflict.


As you see, the "INFO: "-Lines are what's printed out to the user,
while the other lines could help portage to solve it automatically
(if it has an special logic for this)


cu
-- 
---------------------------------------------------------------------
 Enrico Weigelt    ==   metux IT service - http://www.metux.de/
---------------------------------------------------------------------
 Please visit the OpenSource QM Taskforce:
 	http://wiki.metux.de/public/OpenSource_QM_Taskforce
 Patches / Fixes for a lot dozens of packages in dozens of versions:
	http://patches.metux.de/
---------------------------------------------------------------------
-- 
gentoo-dev@g.o mailing list