public inbox for gentoo-dev@lists.gentoo.org
 help / color / mirror / Atom feed
From: Mikael Andersson <snikkt@telia.com>
To: Jon Portnoy <avenj@gentoo.org>, gentoo-dev@gentoo.org
Subject: Re: [gentoo-dev] uninstalling packages with portage
Date: Wed, 27 Aug 2003 10:27:24 +0200	[thread overview]
Message-ID: <200308271027.27987.snikkt@telia.com> (raw)
In-Reply-To: <20030827003722.GA9653@cerberus.oppresses.us>

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


  reply	other threads:[~2003-08-27  8:24 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-08-26 22:58 [gentoo-dev] uninstalling packages with portage Andrew Gaffney
2003-08-26 23:02 ` Cedric Veilleux
2003-08-26 23:14   ` Andrew Gaffney
2003-08-26 23:01     ` Stuart Herbert
2003-08-26 23:19     ` Georgi Georgiev
2003-08-27  0:08   ` Michael Cummings
2003-08-27  0:15     ` Jon Portnoy
2003-08-27  0:32       ` Michael Cummings
2003-08-27  0:37         ` Jon Portnoy
2003-08-27  8:27           ` Mikael Andersson [this message]
2003-08-27  8:37             ` Jason Stubbs
2003-08-27  6:24       ` Rajiv Aaron Manglani
2003-08-27  7:11         ` Thomas de Grenier de Latour
2003-08-27  7:27           ` Jon Portnoy
2003-08-27  7:53             ` Thomas de Grenier de Latour
2003-08-27  8:00               ` Jon Portnoy

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200308271027.27987.snikkt@telia.com \
    --to=snikkt@telia.com \
    --cc=avenj@gentoo.org \
    --cc=gentoo-dev@gentoo.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox