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 1JmYOF-0006CA-9G for garchives@archives.gentoo.org; Thu, 17 Apr 2008 17:59:19 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id C1FC5E0609; Thu, 17 Apr 2008 17:59:17 +0000 (UTC) Received: from s15216962.onlinehome-server.info (s15216962.onlinehome-server.info [217.160.22.205]) by pigeon.gentoo.org (Postfix) with ESMTP id 7CC8AE0609 for ; Thu, 17 Apr 2008 17:59:17 +0000 (UTC) Received: (from uucp@localhost) by s15216962.onlinehome-server.info (8.13.3/8.13.3) with UUCP id m3HHxHsd005768 for gentoo-dev@lists.gentoo.org; Thu, 17 Apr 2008 19:59:17 +0200 Received: (from weigelt@localhost) by nibiru.metux.de (8.12.10/8.12.10) id m3HHwRGN031361 for gentoo-dev@lists.gentoo.org; Thu, 17 Apr 2008 19:58:27 +0200 Date: Thu, 17 Apr 2008 19:58:27 +0200 From: Enrico Weigelt To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] What are blocks used for? Message-ID: <20080417175827.GF31409@nibiru.local> References: <20080416062452.45f3831d@snowcone> 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: <20080416062452.45f3831d@snowcone> 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: d71429b3-f027-42a4-8cdc-e5b38b894617 X-Archives-Hash: 9b0b76ac9ea5987424ea2e3ee45ca165 * Ciaran McCreesh schrieb: Hi, > b) Marking that two related implementations are mutually incompatible at > runtime because they both provide the same binary. Classical example: MTA's: Traditionally they tend to provide an /usr/sbin/sendmail executable. So you can't have multiple MTAs installed. Here the problem isn't that portage can't give more advise, but the system only allows one MTA. Portage itself can't help here in any ways - it's all up to the ebuilds. An clean solution is changing the MTAs to be not conflicting (using separate filenames, etc) and having some frontend for these commands, which chooses the right MTA to call on some configuration. AFAIK, this is exactly what mailwrapper does :) Same applies to things like java-config, etc. > c) Marking that a file that used to be provided by one package is now > provided by another package that is either depending upon or depended > upon by the original package. Do you mean something like this ? * package foo -> has: /usr/bin/foo * package bar -> depends: foo -> has: /usr/bin/foo > For example, for class d) blocks such as the recent coreutils / mktemp mess, Yes, this is *really* a mess, especially because critical packages are involved here. IMHO the problem is clearly made by the two packages themselves. Actually I didn't track yet who was first, but according to the ebuilds, the conflict arises w/ 6.10 (not yet in 6.9). IMHO the external mktemp should be preferred and the coreutils's one skipped. > the package manager can suggest to the user to install the new package and > then uninstall the old package, rather than forcing the user to uninstall > the old package by hand (possibly leaving their system without critical > utilities) and then install the new package. Yes, but this requires the ebuild author to provide enough information *very carefully*. In this specific case, portage could automatically decide to replace the separate mktemp package by newer coreutils. But what happens if some package depends on the mktemp package ? Portage has to catch these deps and map them to coreutils if they provide mktemp (and only for those versions which *really do*). This all adds a lot of complexity, and I doubt it's really worth it. Removing mktemp and properly maintaining the standalone package seems much easier and cleaner to me. 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