From owner-freebsd-ports@FreeBSD.ORG Fri Aug 20 03:34:04 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 73BD51065670; Fri, 20 Aug 2010 03:34:04 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) Received: from mail-pv0-f182.google.com (mail-pv0-f182.google.com [74.125.83.182]) by mx1.freebsd.org (Postfix) with ESMTP id 1BF058FC12; Fri, 20 Aug 2010 03:34:03 +0000 (UTC) Received: by pvg4 with SMTP id 4so1190301pvg.13 for ; Thu, 19 Aug 2010 20:34:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:mime-version :content-type:from:in-reply-to:date:cc:content-transfer-encoding :message-id:references:to:x-mailer; bh=AcjDLdtOQoc4EaOWwlSYncmSUQHGzkHdrXMo1s5kOxI=; b=Sbq7jGZCIdTj5RprqFgapjkQD3RtOgjjXrPytmrK3dmlfBuv4nNsNM3WgFCAStgpLw KivZmxvTgOe1OL00p1jhkX3OcFNTVZkVoaTlo77qXK3dbbLPxTAqthwBPBhRAySR1XzC XtL8W3WxVberyg6BE5Md3XQLtq6hrVQVYhC7Y= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=s3bvcljEmU6ne4d91ZBAgAOcd8SEkxuUYpsIzebGrHzZo09rsZwZWICg6juWdL3ch2 ruJaVvwQJdjoPCT81Pwa7mJKoBTNUYwZZgj95oWA67wRgNOn5J/nBNzu7GDcD/CypWKL I45AT9iAlVetU/mzcrT9JKRT5H3xIBZHadPTY= Received: by 10.115.75.20 with SMTP id c20mr844153wal.186.1282273698633; Thu, 19 Aug 2010 20:08:18 -0700 (PDT) Received: from [192.168.0.203] (deviant.freebsdgirl.com [173.8.183.73]) by mx.google.com with ESMTPS id d39sm3899376wam.4.2010.08.19.20.08.16 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 19 Aug 2010 20:08:17 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Garrett Cooper In-Reply-To: <4C6DE8DB.8010202@DataIX.net> Date: Thu, 19 Aug 2010 20:08:15 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20100819143830.GJ35140@azathoth.lan> <4C6DA0FA.7080203@DataIX.net> <4C6DE8DB.8010202@DataIX.net> To: jhell X-Mailer: Apple Mail (2.1081) Cc: bapt@FreeBSD.org, Florent Thoumie , Julien Laffaye , David Forsythe , Garrett Cooper , 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 03:34:04 -0000 On Aug 19, 2010, at 7:30 PM, jhell wrote: > 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: >>>>>>=20 >>>>>> ${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. >>=20 >=20 > You may have misunderstood or maybe not the intention behind that = file. >=20 > 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. >=20 > -- 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. This is part of the request that someone was making for a feature like = Gentoo's world file on the forums: = http://forums.freebsd.org/showthread.php?t=3D16963 . Personally it's one of the takeaways I like about Gentoo's portage = system because it's easy to track what I as a user installed manually, = and hence, it's easy to track what can be removed (instead of using = pkg_cutleaves) if we have a `emerge -C` (package dependency [dist]clean = equivalent). It also makes it easier for admins to mass install packages = on multiple machines using a smaller `distroot' install binary base, so = all I would have to do is: 1. Install prebuilt version of FreeBSD with sysinstall / ad hoc = installer method. 2. Say, pkg_add 3. Do whatever I need to do to configure the machine. Done. That would make system administration really easy and slick, and would = improve the setup process for corporations that build on a static = FreeBSD base for several releases and have varying packages for several = bits. I know if my group did it, things wouldn't be such a mess.. By the way... /var/lib/portage/world is a simple text file composed line = by line like: i.e. devel/gcc46 lang/python26 www/firefox36 etc. Simple and easy to understand, and easy to modify :). > 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. >=20 > 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. >=20 > 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. I agree that it's high time that a freebsd-packaging@ list be created. = sysinstall has its own list now -- we should have one for the packaging = software too :). > 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. I think that you're adding unnecessary complexity to the overall issue. = It really doesn't make sense for me to install packages that aren't = available for my architecture for one (in particular today), unless you = were thinking of serving up this data on an NFS server, but even then it = doesn't make sense because almost all of these files are hardcoded to = exist at ${LOCALBASE} when built as ports, so setting it to another = location would be problematic. Other things would need to be done before = you could get to this stage. Also, many of the ports installed are prefixed with the package name, = which is different for multiple ports. Example: $ ls /var/db/pkg/python* python-2.6,2/ python26-2.6.5_1/ python31-3.1.2_1/ Having a concept of multiple versions in ports would require a major = overhaul to get things to work in a Gentoo like method, and I'm not sure = how many people would be particularly keen in doing this (especially = when there are name collisions in installed package files). Oh, and there was the tunable packages idea (what I originally called = `fat packages', but Julien has done work on `fat packages', so I'll = yield to that usage :P), where the contents of packages could be tuned = according to config options requested by end-users and/or set by package = maintainers, to get the granularity of distributing orthogonal features = for packages, like xorg-server-hal-support xorg-server-no-hal-support = (or whatever the proper title would be). The emphasis that Florent made too was to remove crud in pkg_install and = libpkg and get things down to more of a library form so we could develop = thin wrappers above pkg_install with logical functions (like apt-get, = yum, etc does with fetching, whereas rpm does with installation, etc), = instead of maintaining pkg_install the way it is today. Thanks, -Garrett=