From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9969 invoked from network); 21 Jul 2004 15:28:02 +0000 Received: from smtp.gentoo.org (156.56.111.197) by lists.gentoo.org with AES256-SHA encrypted SMTP; 21 Jul 2004 15:28:02 +0000 Received: from lists.gentoo.org ([156.56.111.196] helo=parrot.gentoo.org) by smtp.gentoo.org with esmtp (Exim 4.34) id 1BnJ0k-0005gI-79 for arch-gentoo-dev@lists.gentoo.org; Wed, 21 Jul 2004 15:28:02 +0000 Received: (qmail 29997 invoked by uid 89); 21 Jul 2004 15:26:59 +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 6989 invoked from network); 21 Jul 2004 15:26:58 +0000 X-Mailer: exmh version 2.6.3 04/02/2003 (gentoo 2.6.3) with nmh-1.1 To: gentoo-dev@lists.gentoo.org In-Reply-To: Message from Jason Wever of "Wed, 21 Jul 2004 07:43:01 MDT." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 21 Jul 2004 17:25:06 +0200 From: aeriksson@fastmail.fm Message-Id: <20040721152507.296CE3F03@latitude.mynet.no-ip.org> Subject: Re: [gentoo-dev] Revisiting GLEP 19 X-Archives-Salt: dc6a5031-938b-4cae-a892-ac33d907a8b1 X-Archives-Hash: 46691ccd465a845864a6e018f8d919dc weeve@gentoo.org said: > I personally would very much like to leave ChangeLogs as they are. > We already have tools to make sure they are in the right format > (though repoman doesn't check for it and yes developers can choose > not to use these tools). I think changing them over to XML would > be more overhead in file size and in required tools to parse them > than is really necessary. If the problem is that people can't > follow directions, then don't punish those of us who do. I second that feeling. If what we're trying to achieve is to have a way to signal to the sysadmins that a security update is present, why not just add a [S] entry to 'emerge -pv'? That way the community packaging gentoo can stay on step with the development of the upstream project (low cost), and the sysadmin was to decide (and take the cost) for doing the upgrade of his installed packages with security holes. Doing this would put some stress on the ability to run different packages from different eras together on the same box. The flexible dependency system we have today _should_ prove useful to make that happen, and if there are packages with too tight requirements on versions of other packages it uses, we should bring that issue up with the upstream project. Taking it upon ourselves to do backports etc is just to costly, imho. /A -- gentoo-dev@gentoo.org mailing list