From owner-freebsd-ports@FreeBSD.ORG Sat Dec 25 14:02:22 2010 Return-Path: Delivered-To: freebsd-ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 183EC106564A; Sat, 25 Dec 2010 14:02:22 +0000 (UTC) (envelope-from varga.michal@gmail.com) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 6A2808FC08; Sat, 25 Dec 2010 14:02:21 +0000 (UTC) Received: by bwz12 with SMTP id 12so1559999bwz.13 for ; Sat, 25 Dec 2010 06:02:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:from:to:cc :in-reply-to:references:content-type:organization:date:message-id :mime-version:x-mailer:content-transfer-encoding; bh=BJS2UgRzQwOpXdWz306GJyDp9wGka5m5/7mj8eNhBQk=; b=TyuAZF6b7VbYn32Ik3MDMh6Wyu51LOyikoFG11wYolEJQdXKvRMTl+vFp1mw8bJRWN /CtOwZlwMZB7vGyvNQAhY8scA8oWEkYCrGfoHhhBnzyspbAi0KtBJarI0h/M/k0/Sp2E Xkf2rBV2z5qcTOoQhyC8qL2x8uEjKL8RIhTS8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:from:to:cc:in-reply-to:references:content-type:organization :date:message-id:mime-version:x-mailer:content-transfer-encoding; b=gkigBL4FGC0d2CVxqXz0Ow5g8Wc8WAeQN9w747Voz3HPFOiH+lzSaypziXbOkWCAQl gxy8SGHmO04gG6TiT2hNEj1YQ7X84lwH3HGjVyV3Mln/FYwO3UhxxmXZ/q2w/DG9U5UP flfxfiByNgpMBA2kwDLsxooDTTdGVPUsYTqn4= Received: by 10.204.23.66 with SMTP id q2mr1613033bkb.130.1293284003057; Sat, 25 Dec 2010 05:33:23 -0800 (PST) Received: from [10.0.101.2] (254.166.broadband10.iol.cz [90.177.166.254]) by mx.google.com with ESMTPS id b17sm6591920bku.8.2010.12.25.05.33.20 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sat, 25 Dec 2010 05:33:22 -0800 (PST) From: Michal Varga To: David Demelier In-Reply-To: <4D15D275.6000308@gmail.com> References: <4D15D275.6000308@gmail.com> Content-Type: text/plain; charset="UTF-8" Organization: Stonehenge Date: Sat, 25 Dec 2010 14:33:18 +0100 Message-ID: <1293283998.1467.35.camel@xenon> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: dougb@FreeBSD.org, freebsd-ports@freebsd.org Subject: Re: portmaster: print /usr/ports/UPDATING on update X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Dec 2010 14:02:22 -0000 On Sat, 2010-12-25 at 12:16 +0100, David Demelier wrote: > Hi, > > A lot of people always forget to read UPDATING (that's normal we'll are > humans). > > Each entry in UPDATING is like "AFFECTS: users of net-mgmt/flowd" so if > an update of net-mgmt/flowd is available and a *recent* entry in > UPDATING talks about then print the message. > > This can prevent a lot of breakage and useless noise on lists. What do > you think ? > > Merry Christmas and happy holidays ! > > David. Or there is another possibility - find someone vocal enough to finally *enforce* all new entries to UPDATING to be machine readable. You already slightly touched the issue - but what exactly one considers "recent"? I've seen people that don't upgrade anything non-security related for months and some even years, when not directly required as dependency. And those are actually the cases when everything breaks horribly in the end - I guess for obvious reasons. It wouldn't be that hard to reqire all entries in updating to be in a specific and meaningful format, i.e. DATE=20101225 PORT=x11/gnome2 VERSION=2.32.1 SEVERITY=1 # 0 = informational, 1 = critical/showstopper COMMENT=Manually deinstall x11/somethingnolongercool and force recompile devel/libstupid before upgrading to this version of Gnome === Then just let upgrade tools deal with the data as they want, i.e. some really cool ones might show all entries between %my_version% and % current_version% and based on severity, either optionally let users skip over the warning - * /This application no longer ships with skype-voice-whatever plugin, please recheck your configuration/ doesn't really count as show stopping - versus - * Don't allow upgrade process to continue unless user explicitly confirms "Yes, I've totally read that and just finished all the steps required" for cases where there is guaranteed that upgrade *WILL* break without following those steps first. Something like this would finally make UPDATING an integral part of any upgrade process, not just "some half-forgotten text file that one *should* keep an eye on - but usually only after all hell broke loose". m. -- Michal Varga, Stonehenge (Gmail account)