From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11640 invoked from network); 21 Jul 2004 16:36:29 +0000 Received: from smtp.gentoo.org (156.56.111.197) by lists.gentoo.org with AES256-SHA encrypted SMTP; 21 Jul 2004 16:36:29 +0000 Received: from lists.gentoo.org ([156.56.111.196] helo=parrot.gentoo.org) by smtp.gentoo.org with esmtp (Exim 4.34) id 1BnK4y-0001U4-Se for arch-gentoo-dev@lists.gentoo.org; Wed, 21 Jul 2004 16:36:28 +0000 Received: (qmail 25187 invoked by uid 89); 21 Jul 2004 16:36:28 +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 14430 invoked from network); 21 Jul 2004 16:36:27 +0000 X-Mailer: exmh version 2.6.3 04/02/2003 (gentoo 2.6.3) with nmh-1.1 To: stuart@gentoo.org Cc: gentoo-dev@lists.gentoo.org In-Reply-To: Message from Stuart Herbert of "Wed, 21 Jul 2004 16:36:40 BST." <200407211636.40801.stuart@gentoo.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 21 Jul 2004 18:34:35 +0200 From: aeriksson@fastmail.fm Message-Id: <20040721163435.7F10B3F03@latitude.mynet.no-ip.org> Subject: Re: [gentoo-dev] Revisiting GLEP 19 X-Archives-Salt: d7f104ce-0c62-41a7-8abc-f6d1c3054f3d X-Archives-Hash: 95b4425df42e8fe4d145599595e2e113 > On Wednesday 21 July 2004 16:25, aeriksson@fastmail.fm wrote: > > 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'? > > Two things. First off, I'd hope to achieve a lot more than just adding a > [S] entry to emerge -pv. Care to elaborate? "It's nifty for the future" is a bad argument. Far too many times have I came across people who thinks all problems goes away if the solution is implemented using xml (I'm NOT saying you're one of them). Present the problems you want to fix, and we'll discuss them. >> Secondly, where do you think Portage will get the information from >> to decide whether or not to add the [S]? Right now, the design of the >> glsa toolset is to bolt this information onto the side. With XML-based >> changelogs, the information could be stored where it belongs - in the >> list of what has changed and why. Why not add that bit of info the the ebuild which incorporates the fix? "SECURITYFIX=url1 url2 http://www.gentoo.org/GLSA1234whatever" would be all need. For a sysadmin who's not into updating every day for the fun of it, the stream of new ebuilds _with_ SECURITYFIX clauses would constitute 'vertual dependecies" he like to depend on. So from his pow, it's legit ebuild information. Or put the other way around, why not move all the other headers in ebuilds to xml, and use xml-aware tools to execute on them? (joke) BR, /Anders -- gentoo-dev@gentoo.org mailing list