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 1LPQTC-0004Bb-Hm for garchives@archives.gentoo.org; Tue, 20 Jan 2009 23:57:22 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id EB110E0522; Tue, 20 Jan 2009 23:57:20 +0000 (UTC) Received: from rv-out-0708.google.com (rv-out-0708.google.com [209.85.198.244]) by pigeon.gentoo.org (Postfix) with ESMTP id A9C7CE0522 for ; Tue, 20 Jan 2009 23:57:20 +0000 (UTC) Received: by rv-out-0708.google.com with SMTP id b17so3689697rvf.46 for ; Tue, 20 Jan 2009 15:57:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to :content-type:content-transfer-encoding; bh=xUsXDPkEk+HkVyubZo5xKInFKB7n6ChjsabW2guY+3E=; b=l2b+/D5O7Gh8766G8rxyyPMxWGK/mgdJTZMxGEGnrONqZAyEDaYOR+S68lmvdj80Y8 lqVOJyOm0nQU/HcQ1Zw+Y+yRMbNmqWL7R9yuow2omI6mQ+MQQImLz99C+uFbMiMVBmkk Z1C+JAauM3MzeLXmqx6LiAJ3Du3hRPjUuJ8N0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type :content-transfer-encoding; b=ML6fv8HHq0TlBjK9NHWBrItl9HhkX3gx/whFLsVXXq9LK2hxx2nmEG/y/y1Ov6obia oZhJzXUE8f2uvkuahmMlWdfZRBhj8MRJrFEZKrTRZ8herfGoMlpJP6TAL7o35FQF2jBN 6VwU0HGxVy9TTxp7nhA3/x7bwxf8RFJRhfPS0= 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 Sender: jer.gentoo@gmail.com Received: by 10.141.51.10 with SMTP id d10mr3637395rvk.195.1232495840229; Tue, 20 Jan 2009 15:57:20 -0800 (PST) In-Reply-To: <20090120234012.5cff275e@anaconda.krait.us> References: <4976205A.5030600@gentoo.org> <1232479492.31989.140.camel@liasis.inforead.com> <497627F1.5060704@gentoo.org> <1232482733.31989.152.camel@liasis.inforead.com> <49765547.2090408@gentoo.org> <20090120234012.5cff275e@anaconda.krait.us> Date: Tue, 20 Jan 2009 17:57:20 -0600 X-Google-Sender-Auth: 4ad18c1ce111d94f Message-ID: <90b936c0901201557m4a60f306va93fe6f34e2ff11a@mail.gmail.com> Subject: Re: [gentoo-dev] Usage of cp -i to prevent overwriting upstream files From: Jeremy Olexa To: gentoo-dev@lists.gentoo.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Archives-Salt: 1463eaac-6055-4c3f-8937-603451f29a8f X-Archives-Hash: 8cb7a010bac02e49448e4942c4db733b On Tue, Jan 20, 2009 at 5:40 PM, Ferris McCormick wrote= : > On Tue, 20 Jan 2009 23:50:47 +0100 > Jan Kundr=C3=A1t wrote: > >> Ferris McCormick wrote: >> > 'cp -i' will at least ask a question, and I find that marginally bette= r >> > --- it's confusing, but at least it says something. But it seems to m= e >> > that if we hit this case, no one (including the package owner) knows >> > which .xml file to use, so stopping the build makes sense, but do it >> > with some message that explains exactly what is going on. >> >> The problem is that the whole build won't *abort*, but rather become >> interactive. >> >> I for one think that having it die (in the unlikely case that s >> developer made a mistake) is better than letting it hang indefinitely >> (in the unlikely case that a developer made a mistake) :). > > That's what I meant by "stopping the build". My concern is that when > we do stop the build, we do it with some useful error message and make > it clear that the user did not screw up and so should do something to > fix it. ("die file exists" looks to me like an attempt to ask the user > to fix something, not an ebuild problem.) Sure. Makes sense. > > As I think about it, I am not sure how this could happen. It would > either be an ebuild that the package owner never tried or a change in > the source file. And why wouldn't a change in the source file cause an > immediate termination because the length would suddenly be wrong? And Regardless of *how* it happens, my only point is to not put any interactiveness in ebuilds for *whatever* reason. If it does prompt for a response (again, for whatever reason) then all of portage's background features are "broke" (waiting for input). So, as I suggested in irc, the two solutions are to use the suggested method in the OP or to set PROPERTIES=3Dinteractive in the ebuild..either way will work. I would personally avoid the properties route on ebuilds that I write though because it doesn't *need* to be interactive. -Jeremy > if the now-upstream-supplied build.xml file is different from the one > the developer put together, wouldn't you probably want a revision bump > at that point? >> Think about >> insane users setting up cronjobs and what not... >> >> Cheers, >> -jkt >> >> -- >> cd /local/pub && more beer > /dev/mouth >> > Clearly, I misspoke when I said I'd not respond further. :) > > Regards, > Ferris > -- > Ferris McCormick (P44646, MI) > Developer, Gentoo Linux (Sparc, Userrel, Trustees) >