From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16972 invoked by uid 1002); 27 Aug 2003 08:24:35 -0000 Mailing-List: contact gentoo-dev-help@gentoo.org; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@gentoo.org Received: (qmail 28396 invoked from network); 27 Aug 2003 08:24:35 -0000 From: Mikael Andersson To: Jon Portnoy , gentoo-dev@gentoo.org Date: Wed, 27 Aug 2003 10:27:24 +0200 User-Agent: KMail/1.5.3 References: <3F4BE61E.50600@technaut.darktalker.net> <20030827003202.GB6635@enki.datanode.net> <20030827003722.GA9653@cerberus.oppresses.us> In-Reply-To: <20030827003722.GA9653@cerberus.oppresses.us> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200308271027.27987.snikkt@telia.com> Subject: Re: [gentoo-dev] uninstalling packages with portage X-Archives-Salt: 69b0bce6-a941-4ea0-8248-2c84680cffa1 X-Archives-Hash: d5a51669ecc3b845d60ccc46f1802c1c On Wednesday 27 August 2003 02.37, Jon Portnoy wrote: > On Tue, Aug 26, 2003 at 08:32:02PM -0400, Michael Cummings wrote: > > I think the point is, why do they not block each other? Shouldn't they? > > > > Not that this is part of the original thread :) > > Why should they? netkit-base is a package that happens to provide > ping among other utilities; because all of them except the old-style > inetd are deprecated (old-style inetd is deprecated but some people > still prefer it, for whatever reason). It no longer provides ping, just > old-style inetd. > > Block each other in what way? How do you know before getting to the > merge stage that files might be conflicting? > I agree that we can't block them because we don't know _before_ the merge stage. But at the merge stage it should be posssible to check if the files are included in another (already installed) ebuild. This would of course require that such information is present in a way that it can be done reasonably fast. My suggestion is to present this as a warning/information to the user. For example by outputting the relevant merge line (<<<) with ewarn. But more important is to record these conflict so that portage can issue a warning before an unmerge that package-such-and-such will be broken and need to be rebuild. > The only real solution that I can see is preventing it from happening in > the first place. > > Here's something in the same vein: > http://bugs.gentoo.org/show_bug.cgi?id=18181 > > I guess we need to determine which package provides the best version of > kill. In that case, it's not that much of a big deal because most people > are going to be using their shell's internal kill command anyway, > though. I think both ways are good. One way to detect conflicts and then work with ebuilds/blocking etc to resolve them more permanently. /Mikael Andersson -- gentoo-dev@gentoo.org mailing list