From owner-freebsd-current@FreeBSD.ORG Mon Jul 15 16:27:21 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 00392FEF; Mon, 15 Jul 2013 16:27:20 +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 B7CD7879; Mon, 15 Jul 2013 16:27:20 +0000 (UTC) Received: from smtp.fisglobal.com ([10.132.206.16]) by ltcfislmsgpa01.fnfis.com (8.14.5/8.14.5) with ESMTP id r6FGRKFt027095 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 15 Jul 2013 11:27:20 -0500 Received: from LTCFISWMSGMB21.FNFIS.com ([10.132.99.23]) by LTCFISWMSGHT05.FNFIS.com ([10.132.206.16]) with mapi id 14.02.0309.002; Mon, 15 Jul 2013 11:27:19 -0500 From: "Teske, Devin" To: Baptiste Daroussin 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/QjEhM8pplkGukAgAGBDYCAAKd0gA== Date: Mon, 15 Jul 2013 16:27:19 +0000 Message-ID: <13CA24D6AB415D428143D44749F57D7201FC7489@ltcfiswmsgmb21> References: <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> <13CA24D6AB415D428143D44749F57D7201FC51FE@ltcfiswmsgmb21> <20130715062759.GF1516@ithaqua.etoilebsd.net> In-Reply-To: <20130715062759.GF1516@ithaqua.etoilebsd.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.132.253.121] Content-Type: text/plain; charset="us-ascii" Content-ID: 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-15_04:2013-07-15,2013-07-15,1970-01-01 signatures=0 Cc: Devin Teske , Garrett Wollman , "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: Mon, 15 Jul 2013 16:27:21 -0000 On Jul 14, 2013, at 11:27 PM, Baptiste Daroussin wrote: > On Sun, Jul 14, 2013 at 07:29:50AM +0000, Teske, Devin wrote: >>=20 >>> Or you >>> can maintain the old cruft for your business -- just don't expect >>> anyone else to use it, or even want to. >>>=20 >>=20 >>=20 >> I have no intention of making old-world packages... but I also have no i= ntention of using "pkg create". >=20 > So you are taking as an exemple rpm but with RPM you do want to use what = they do > provide, aka rpmbuild but with pkgng you want to manually handwrite the p= ackages > because we haven't hidden the format behind opaque names and format. >=20 Close... I use rpmbuild because I haven't figured out how to subvert it to = create cpio-balls for rpm(8). I know how to extract the contents of binary = rpm's using rpm2cpio and I know how to extract the meta data and supplant i= t into a template SPECFILE using rpm -q -p file.rpm --qf "queryformat" ... = but I haven't spent enough time with rpm's to know how to master them witho= ut rpmbuild. The best I've done is learn how to use ".rpmmacros" to make rp= mbuild behave in a sane manner that is conducive to (a) building the archiv= e out of the current directory (including all temporary files, etc.) and (b= ) working on source-controlled checkouts. However, even if I did figure out the cpio-ball/metadata format, it is quit= e convenient to have rpmbuild do the work -- which unfortunately introduces= the constraint that you have to generate the archive on the system for whi= ch it will be installed (something you eluded that is inconclusive -- I'll = cover that in a reply to that-reply directly). The convenience however is not because the tool does everything I need it t= o do, but the convenience comes from the translation of YAML into metadata.= It doesn't appear that this will be necessary with pkgng packages, just as= it wasn't necessary for pkg_install packages. To be more clear,... because tools like pkg_create and "pkg create" take a = file-in, add data to it, and then (the most important part) put a modified = form into the archive (which quite-closely resembles the original), it is t= hen possible to imagine that: (1) there's value in learning both the input format and the output format s= o that you can validate packages, fix broken packages, etc. ASIDE: For example... a binary release package ends up with incorrect depen= dencies encoded within its +CONTENTS file -- I can slurp the package into o= ur "pkgbase", adjust the PLIST (generated from +CONTENTS), and produce a fi= xed package in mere moments (and I didn't have to wake anybody in the middl= e of the night, ask that FTP mirrors be updated, balk at the core team -- n= one of that... the problem was solved and in the next release we hope for t= he best that the dependency chain isn't busted for the same binary package = within the set of "X.Y-RELEASE" packages). (2) there's value in writing a shell-script method to translate the input f= ormat into the output format from a system of makefiles calling said shell = scripts out of a revision-controlled checkout ASIDE: This one should be obvious. If you can assemble a package using noth= ing but shell scripts (and mostly awk, ls, find, cp, mkdir, ln, cvs, make, = md5/sha256/sha512/openssl, and etc.), then you don't have to port the "port= " system (our "port" system being called "pkgbase" -- and working to "keep = you stable" rather than "keep you up-to-date"). > You know in that case you should probably create your own RPM without RPM= just > write by hand the header and happened the cpio to it, in that case you wi= ll end > up having the same at what you are trying to do with pkg. >=20 It's a good idea... except one thing... the YAML SPECFILE (minus the elemen= ts that are specific to the `-bb' process of rpmbuild) get completely chang= ed in the process. Doing this would require a YAML parser + metadata encode= r process-pair. Whereas for FreeBSD it's YAML-in, YAML-out. So I don't need= a YAML-parser, just a line-parser and light YAML-encoder -- which could be= fixed-strings, doesn't have to be complex... e.g., awk). --=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.