From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from pigeon.gentoo.org ([69.77.167.62] helo=lists.gentoo.org) by finch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1JmZr7-0004Sk-8j for garchives@archives.gentoo.org; Thu, 17 Apr 2008 19:33:13 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id B7244E06C3; Thu, 17 Apr 2008 19:33:11 +0000 (UTC) Received: from s15216962.onlinehome-server.info (s15216962.onlinehome-server.info [217.160.22.205]) by pigeon.gentoo.org (Postfix) with ESMTP id 73E52E06C3 for ; Thu, 17 Apr 2008 19:33:11 +0000 (UTC) Received: (from uucp@localhost) by s15216962.onlinehome-server.info (8.13.3/8.13.3) with UUCP id m3HJXBa3030384 for gentoo-dev@lists.gentoo.org; Thu, 17 Apr 2008 21:33:11 +0200 Received: (from weigelt@localhost) by nibiru.metux.de (8.12.10/8.12.10) id m3HJVNh1021646 for gentoo-dev@lists.gentoo.org; Thu, 17 Apr 2008 21:31:23 +0200 Date: Thu, 17 Apr 2008 21:31:23 +0200 From: Enrico Weigelt To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] What are blocks used for? Message-ID: <20080417193122.GH31409@nibiru.local> References: <20080416062452.45f3831d@snowcone> <20080416072413.GA23808@comet> Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080416072413.GA23808@comet> User-Agent: Mutt/1.4.1i X-Terror: bin laden, kill bush, Briefbombe, Massenvernichtung, KZ, X-Nazi: Weisse Rasse, Hitlers Wiederauferstehung, 42, X-Antichrist: weg mit schaeuble, ausrotten, heiliger krieg, al quaida, X-Killer: 23, endloesung, Weltuntergang, X-Doof: wer das liest ist doof X-Archives-Salt: f2d2916e-fce1-4c81-916a-e0ebe744d817 X-Archives-Hash: 909a68debc947d1993fb05243ac56d87 * Donnie Berkholz 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@lists.gentoo.org mailing list