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 1Jml2g-0005XP-OC for garchives@archives.gentoo.org; Fri, 18 Apr 2008 07:29:55 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 31A66E06AC; Fri, 18 Apr 2008 07:29:53 +0000 (UTC) Received: from dsrg.mff.cuni.cz (dsrg.mff.cuni.cz [195.113.20.55]) by pigeon.gentoo.org (Postfix) with ESMTP id D8D79E06AC for ; Fri, 18 Apr 2008 07:29:52 +0000 (UTC) Received: from rb5cu63.net.upc.cz ([89.176.226.63] helo=[192.168.1.107]) by dsrg.mff.cuni.cz with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from ) id 1JmZTe-0000p7-Cx for gentoo-dev@lists.gentoo.org; Thu, 17 Apr 2008 21:09:02 +0200 Message-ID: <4807A04A.8050403@gentoo.org> Date: Thu, 17 Apr 2008 21:08:58 +0200 From: Vlastimil Babka User-Agent: Thunderbird 2.0.0.12 (X11/20080303) 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 To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] What are blocks used for? References: <20080416062452.45f3831d@snowcone> <20080417175827.GF31409@nibiru.local> In-Reply-To: <20080417175827.GF31409@nibiru.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -3.0 X-Spam-Level: --- X-Archives-Salt: b891e140-62e3-4d52-b4d5-0c74bcf16106 X-Archives-Hash: 4137cceb9ffd1e74b64fd5e01b7997c0 Enrico Weigelt wrote: > * Ciaran McCreesh schrieb: > > Hi, Hi Enrico, long time no see! >> 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 I see you've been missing this list for a long time. Today it's not politically correct to say bluntly "portage" but "package manager" (PM)! >> 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. Um no, we should not stick with packages forever for historical reasons. >> 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*. Yes, ebuild author should be careful, OTOH the end users wouldn't have to be as much careful as they had to be now when dealing with it themselves. > 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 ? Such deps should obviously be transformed to || ( >=coreutils-6.10 mktemp) beforehand. > Portage has to catch these deps and map them to coreutils if they > provide mktemp (and only for those versions which *really do*). No, it should probably just state there's a dep conflict (as it does now if there are several depends asking for different versions inside one slot). > This all adds a lot of complexity, and I doubt it's really worth it. Stating dep conflict should be less complexity, and yes it's worth it. > Removing mktemp and properly maintaining the standalone package seems > much easier and cleaner to me. Sure, legacy and maintainership burden ftw! I'm tempted to say "we are not debian" but since I'm not council... :( Caster -- gentoo-dev@lists.gentoo.org mailing list