From owner-freebsd-current@FreeBSD.ORG Sun Jul 14 07:29:53 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id A4DC4E30; Sun, 14 Jul 2013 07:29:53 +0000 (UTC) (envelope-from Devin.Teske@fisglobal.com) Received: from mx1.fisglobal.com (mx1.fisglobal.com [199.200.24.190]) by mx1.freebsd.org (Postfix) with ESMTP id 6EAED824; Sun, 14 Jul 2013 07:29:52 +0000 (UTC) Received: from smtp.fisglobal.com ([10.132.206.17]) by ltcfislmsgpa06.fnfis.com (8.14.5/8.14.5) with ESMTP id r6E7TqFE030210 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sun, 14 Jul 2013 02:29:52 -0500 Received: from LTCFISWMSGMB21.FNFIS.com ([10.132.99.23]) by LTCFISWMSGHT06.FNFIS.com ([10.132.206.17]) with mapi id 14.02.0309.002; Sun, 14 Jul 2013 02:29:51 -0500 From: "Teske, Devin" To: Garrett Wollman Subject: Re: [HEADSUP] No more pkg_install on HEAD by default Thread-Topic: [HEADSUP] No more pkg_install on HEAD by default Thread-Index: AQHOgGCkEhI/XtjETUan8/QjEhM8pplkGukA Date: Sun, 14 Jul 2013 07:29:50 +0000 Message-ID: <13CA24D6AB415D428143D44749F57D7201FC51FE@ltcfiswmsgmb21> References: <20130712231637.GS85556@ithaqua.etoilebsd.net> <13CA24D6AB415D428143D44749F57D7201FC2DBD@ltcfiswmsgmb21> <20130713080732.GV85556@ithaqua.etoilebsd.net> <13CA24D6AB415D428143D44749F57D7201FC3AA2@ltcfiswmsgmb21> <13CA24D6AB415D428143D44749F57D7201FC3C92@ltcfiswmsgmb21> <13CA24D6AB415D428143D44749F57D7201FC3FAA@ltcfiswmsgmb21> <201307140613.r6E6Dsov002016@hergotha.csail.mit.edu> <201307140706.r6E76Kg0002959@hergotha.csail.mit.edu> In-Reply-To: <201307140706.r6E76Kg0002959@hergotha.csail.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.132.253.126] Content-Type: text/plain; charset="us-ascii" Content-ID: <881282E540AE6644A297F2197E8FFAFD@fisglobal.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.10.8794, 1.0.431, 0.0.0000 definitions=2013-07-14_01:2013-07-12,2013-07-14,1970-01-01 signatures=0 Cc: Devin Teske , "freebsd-current@freebsd.org" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: Devin Teske List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Jul 2013 07:29:53 -0000 On Jul 14, 2013, at 12:06 AM, Garrett Wollman wrote: > In article <20130714064601$3ce5@grapevine.csail.mit.edu>, > dteske@freebsd.org writes: >=20 >>> [I wrote:] >>> It accesses the sqlite database in /var/db/pkg that was previously >>> retrieved from the remote repository. >=20 >> Now from what you explained of pkg, I'm worried that for bsdconfig: >>=20 >> 1. Browse packages (nothing else) >> 2. Exit bsdconfig >>=20 >> and now because the "pkg rquery" has staged a db, future "pkg" commands >> are now influenced. >=20 > Only if you update /usr/local/etc/pkg.conf to set a permanent > PACKAGESITE. Otherwise, it will notice that the remote repo catalog > you have isn't for your currently selected remote repo, and use that > instead. >=20 >>> You really shouldn't know about the actual format of the tarballs; >>> your time would be better spent learning the new "pkg create", "pkg >>> register", and "pkg repo" commands. Depending on your needs, you >>> might want to write to the libpkg API instead. >=20 >> That won't work for us. >>=20 >> You're not going to like the answer, but it does mean that things like >> "pkg create", "pkg register" and "pkg repo" won't work for us. >=20 > Congratulations for building your entire workflow around a horrible > kluge straight out of 1993. Prejudice much? > FreeBSD, however, is moving on. Moving from tarballs to tarballs, yep... moving along nicely. > (And > it's long past time!) I love your enthusiastic embrace. > Your developers will just have to deal. You're making the wrong argument. Bringing in a new package system doesn't help developers or integrators. It= doesn't matter if you switch "pkg_create" with "pkg_create". Developers li= ke being able to go into a build tree and say "make" and end-up with a pack= age. How that build tree does it should be "sufficiently advanced enough to be i= ndistinguishable from magic." Your answer implies that this infrastructure is unnecessary, when I can ind= eed tell you that even if it is not divulged to me what goes into a package= , I'll still end up ripping it open and creating my own build platform that= doesn't depend on platform-specific tools. And when the day comes that FreeBSD uses something other than tarballs, the= n I'll then force the developers to build the packages on the platform usin= g said tools; but until then, why pigeon-hole the process of building a pac= kage into one OS when developers could care less whether their "make" uses = pkg_create, pkg, rpm, dpkg, or what else? To give you an idea as to just how helpful this is... Imagine the following hierarchy: src/pkgbase/depend/mystuff/script1 src/pkgbase/depend/mystuff/textfile1 src/pkgbase/depend/mystuff/sourcefile.c src/pkgbase/depend/mystuff/Makefile You are a developer. You want to ship a package that contains "script1", "t= extfile1", and "binary1" (which is compiled by saying "make" to turn "sourc= efile.c" into "binary1") You want to ship 8 types of packages: FreeBSD-4.11 FreeBSD-8.1 (i386) FreeBSD-8.1 (amd64) RedHat EL 4 RedHat EL 6 (i386) RedHat EL 6 (x86_64) Debian Wheezy Debian Wheezy 64-bit This is where my framework comes in-handy... cd ~/src/pkgbase/freebsd/RELENG_4/category/mystuff make # it pulled the necessary bits from "src/pkgbase/depend/mystuff" and built = the .tgz cd ~/src/pkgbase/freebsd/RELENG_8/category/mystuff make # it pulled the necessary bits from the "depend" dir and built .tbz cd ~/src/pkgbase/redhat/rhel4/category/sub-category/mystuff make # pulled in "depend" and made .rpm cd ~/src/pkgbase/redhat/rhel6/category/sub-category/mystuff make # pulled in "depend" and made .rpm etc. Of course, *any* time the depend tree has binaries in it... you have to fir= st do a make in there on the platform you want to ship the binary for, and = then do "make depend" in the platform-specific tree to pull in the binaries= . Once you've done that, you don't have to muck with the depend tree again = unless there are changes there. So, I assume that your prejudice remarks are because you haven't either see= n (a) such a platform or (b) such a need for said platform. Yeah, I could rewrite the freebsd-specific logic to use "pkg create", but l= et me tell you... When you have to touch a file that needs to get shipped out to multiple pla= tforms... It's damned nice to be able to build the FreeBSD packages under RedHat *BEC= AUSE* the redhat RPMs can't be built under anything else (building an RPM o= n FreeBSD and attempting to install it on RedHat results in an error messag= e similar to "this is an rpm for FreeBSD; go away"). Whereas FreeBSD will never balk about a package built on another platform. It's a huge time-saving measure... not having to jump over to each/every un= ique platform to package things up *IF/WHEN* you know that there are no bin= aries in the package *or* you've already checked the pre-compiled binaries = into the arch-specific hierarchy. > Or you > can maintain the old cruft for your business -- just don't expect > anyone else to use it, or even want to. >=20 I have no intention of making old-world packages... but I also have no inte= ntion of using "pkg create". --=20 Devin _____________ The information contained in this message is proprietary and/or confidentia= l. If you are not the intended recipient, please: (i) delete the message an= d all copies; (ii) do not disclose, distribute or use the message in any ma= nner; and (iii) notify the sender immediately. In addition, please be aware= that any message addressed to our domain is subject to archiving and revie= w by persons other than the intended recipient. Thank you.