From owner-freebsd-ports@FreeBSD.ORG Fri Aug 20 02:30:56 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 1C1201065675; Fri, 20 Aug 2010 02:30:56 +0000 (UTC) (envelope-from jhellenthal@gmail.com) Received: from mail-yw0-f54.google.com (mail-yw0-f54.google.com [209.85.213.54]) by mx1.freebsd.org (Postfix) with ESMTP id 36D518FC12; Fri, 20 Aug 2010 02:30:54 +0000 (UTC) Received: by ywk9 with SMTP id 9so1267411ywk.13 for ; Thu, 19 Aug 2010 19:30:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:content-type:content-transfer-encoding; bh=L9p0Iz7tuaDZEfiWS9DmvP3dbPkRJ3AcgFAAnxuMCIQ=; b=kVtG7TrEd7hlbt00TZ1DKBeIdTL4oh36al6rR7h8d/p+eDbzJT7ZPUVJXcJ0m+tbbp misNG1d4akqtODtQSyF7j5nW45PbDk6efxjmalGRWwvfDGp/DSBGteT7oaDtpWKICvGT zOawD1W91xZyhXIayXbDgUMlTck6Sl+ujn65o= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; b=SV1RWrSZoxob5LKtUs80fQG2o3ttvgg2KlFEY9f24H6jIdw3YMaClzwwDvnQsrO42q d//5OzrcIywjCCknQseO6kWEhPcZ/CwyQP2umrybKRQ1W8aND9MKI/VZ+5XOmCgEZ1IR NQMhagAVUehlx+xVMdlw0VPB2+ZwzhaLcsPBM= Received: by 10.101.176.2 with SMTP id d2mr842168anp.101.1282271453739; Thu, 19 Aug 2010 19:30:53 -0700 (PDT) Received: from centel.dataix.local ([99.190.84.182]) by mx.google.com with ESMTPS id p16sm3502245anh.15.2010.08.19.19.30.52 (version=SSLv3 cipher=RC4-MD5); Thu, 19 Aug 2010 19:30:53 -0700 (PDT) Sender: "J. Hellenthal" Message-ID: <4C6DE8DB.8010202@DataIX.net> Date: Thu, 19 Aug 2010 22:30:51 -0400 From: jhell User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.2.8) Gecko/20100806 Lightning/1.0b1 Thunderbird MIME-Version: 1.0 To: Garrett Cooper References: <20100819143830.GJ35140@azathoth.lan> <4C6DA0FA.7080203@DataIX.net> In-Reply-To: X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: bapt@FreeBSD.org, Florent Thoumie , Julien Laffaye , David Forsythe , Tim Kientzle , Ivan Voras , freebsd-ports@FreeBSD.org Subject: Re: what next for the pkg_install rewrite 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: Fri, 20 Aug 2010 02:30:56 -0000 On 08/19/2010 21:26, Garrett Cooper wrote: > On Thu, Aug 19, 2010 at 3:10 PM, Ivan Voras wrote: >> > On 19/08/2010, jhell wrote: >>> >> Adding to this I would like to see a central database created for >>> >> packages that have been removed like in Slackware Linux. They keep a >>> >> file in /var/log/preserved_packages with a flat text format with the >>> >> file name looking like: >>> >> >>> >> ${PORTNAME}-${PORTVERSION}${PORTREVISION}-`date +%Y%m%d%H%M%S` > Please no. We need another ad hoc text format like we need holes in our head. > You may have misunderstood or maybe not the intention behind that file. This is just simply a log file of the transactions that were performed upon package deletion and nothing more but just a way for the user to look back and say "HEY! how did that get there!." or "where in the ``jhell'' did that file come from!" that they can simply grep the package removal logs to find out. -- Shameless plug with my email name put in for humor. It is also really handy if you remove some packages that somehow the depends had been messed up and later on your having a problem with a missing lib, easy enough to grep the removal logs to find out what package held that file. Especially useful if you only use binary packages. There is a lot of information that can be logged, especially with '-v', I personally do not think we or anyone for that matter should pass up that opportunity to make sure the information is collected rather than leaving it up to the user to redirect or script(1) the output every time which they would still or should be able to do. Another approach that I have not seen talked about here is a proposed directory layout. I think before 'unless I missed it' that someone jumps into this, some standards & goals should be made and made quite loudly as to attract as much public opinion and suggestions as possible for what works, what does not & what people would like to see. Something of this magnitude like changing packaging databases and directory structures and all that involved needs a central place and a clear, clean plan to be developed properly. I personally do not see this list anymore as a proper place to discuss it. packaging@ list request ? so this can all be centralized. Regards, PS: I have been toying with the idea of the directory layout just for spurring thoughts of others. http://bit.ly/aNLhNU but until there is a central place for these things it does not mean much. -- jhell,v