From owner-freebsd-current@FreeBSD.ORG Mon Jul 15 16:45:45 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 A0BF9D20; Mon, 15 Jul 2013 16:45:45 +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 5ABDEA2A; Mon, 15 Jul 2013 16:45:44 +0000 (UTC) Received: from smtp.fisglobal.com ([10.132.206.16]) by ltcfislmsgpa02.fnfis.com (8.14.5/8.14.5) with ESMTP id r6FGjfrL021181 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 15 Jul 2013 11:45:41 -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:45:41 -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/QjEhM8pplkGukAgAB+HwCAAB8QgIAA5XOAgACq/oA= Date: Mon, 15 Jul 2013 16:45:40 +0000 Message-ID: <13CA24D6AB415D428143D44749F57D7201FC7550@ltcfiswmsgmb21> References: <13CA24D6AB415D428143D44749F57D7201FC3AA2@ltcfiswmsgmb21> <13CA24D6AB415D428143D44749F57D7201FC3C92@ltcfiswmsgmb21> <13CA24D6AB415D428143D44749F57D7201FC3FAA@ltcfiswmsgmb21> <201307140613.r6E6Dsov002016@hergotha.csail.mit.edu> <201307140706.r6E76Kg0002959@hergotha.csail.mit.edu> <13CA24D6AB415D428143D44749F57D7201FC51FE@ltcfiswmsgmb21> <7325EE70-8821-4350-9D8A-E5CAAC548FE9@bayofrum.net> <13CA24D6AB415D428143D44749F57D7201FC59E8@ltcfiswmsgmb21> <20130715063339.GG1516@ithaqua.etoilebsd.net> In-Reply-To: <20130715063339.GG1516@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] 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 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: Chris Rees , 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:45:45 -0000 On Jul 14, 2013, at 11:33 PM, Baptiste Daroussin wrote: On Sun, Jul 14, 2013 at 04:52:26PM +0000, Teske, Devin wrote: On Jul 14, 2013, at 8:01 AM, Chris Rees wrote: On 14 Jul 2013, at 08:29, Teske, Devin wrote: Simple, really. Let's take RPM for example. The RPM package format has been ported to other= platforms. So does pkgng ported on Linux, OS X, dragonfly, NetBSD... Sweet! (bright future!) But, I can't take archivers/rpm4 and build on RPM on FreeBSD and install it= on RedHat. Yes you can, I do it at work all the time, on FreeBSD I do create AIX rpms = and RedHat rpms. What version of RedHat? Worked on RedHat EL4 using rpm3, but in-practice -- attempts to recreate th= at workflow on RedHat EL6 using rpm4 have failed. Please see a copy/paste of the output of when we build an RPM on FreeBSD-8.= 1 and try to install it on RedHat Enterprise Linux 6: http://pastebin.com/zpzjxP2T Spoiler: "package {X} is intended for a freebsd operating system" (not inst= alled) This is because the RPM format records the platform that you "build" your R= PM on (not the binaries, just the RPM) *into* said RPM. So does pkgng. Good to know. This actually adds a requirement to the RPM production that the RPMs be pro= duced on the platform that they will be installed-to. No. Yes. See pastebin link above. Currently, no such restriction exists for the building of FreeBSD packages = (within our system). This would have been true if we had ported pkg_create = (and may continue to be true if we ported pkg and its ilk), but let's say f= or the sake of argument that the future of "pkg" looks bright and it gets p= orted to all sorts of systems (ported in a fashion similar to RPM) *and* we= find one day that the +MANIFEST starts containing a target-platform (resul= ting in refusal to install a *.txz package because it was rolled on a diffe= rent platform. Thank for describing the exact situation pkg is right now. Glad to help ;D (not so happy about the target platform being recorded -- is there an overr= ide? setting UNAME_{a,r,etc.}?) In that case, we'd then prefer to by-pass the tools and use our own method = of creating the tar-ball to lift such a restriction. The restriction you are speaking about does not exists. See pastebin link above. ASIDE: If I knew how to force rpmbuild into creating androgynous packages f= or other architectures, I'd be doing that to life the restriction there too= , but I haven't figured out that. Basically... within our "pkgbase" tree, we like the branch within the tree = to dictate how a package is built... not what platform you're on. The goal = being that we can run a single package-build host that builds all of our pa= ckages from a single platform. You can do it with pkgng just easily, as well as you can do it with rpm. W/respect to RPM, see pastebin link above. -- 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.