From owner-freebsd-current@FreeBSD.ORG Mon Jul 15 01:08:13 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 8E339222; Mon, 15 Jul 2013 01:08:13 +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 4E961C7D; Mon, 15 Jul 2013 01:08:13 +0000 (UTC) Received: from smtp.fisglobal.com ([10.132.206.15]) by ltcfislmsgpa01.fnfis.com (8.14.5/8.14.5) with ESMTP id r6F183Sv027545 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sun, 14 Jul 2013 20:08:03 -0500 Received: from LTCFISWMSGMB21.FNFIS.com ([10.132.99.23]) by LTCFISWMSGHT04.FNFIS.com ([10.132.206.15]) with mapi id 14.02.0309.002; Sun, 14 Jul 2013 20:08:02 -0500 From: "Teske, Devin" To: Adrian Chadd 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+HwCAAB8QgIAAIRYAgABpYoA= Date: Mon, 15 Jul 2013 01:08:01 +0000 Message-ID: <13CA24D6AB415D428143D44749F57D7201FC61A8@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> <13CA24D6AB415D428143D44749F57D7201FC51FE@ltcfiswmsgmb21> <7325EE70-8821-4350-9D8A-E5CAAC548FE9@bayofrum.net> <13CA24D6AB415D428143D44749F57D7201FC59E8@ltcfiswmsgmb21> In-Reply-To: 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="iso-8859-1" Content-ID: <5B2CFC1C7F28BB4F9D5EB9C07ACA02DD@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_07:2013-07-12,2013-07-14,1970-01-01 signatures=0 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 01:08:13 -0000 On Jul 14, 2013, at 11:50 AM, Adrian Chadd wrote: > ... I bet you could do that. I bet you could build the rpm inside a > linux jail and have the relevant uname bits overridden in the right > way. >=20 There's an idea. --=20 Devin > On 14 July 2013 09:52, Teske, Devin wrote: >>=20 >> On Jul 14, 2013, at 8:01 AM, Chris Rees wrote: >>=20 >>> On 14 Jul 2013, at 08:29, Teske, Devin wrote: >>>>=20 >>>> To give you an idea as to just how helpful this is... >>>>=20 >>>> Imagine the following hierarchy: >>>>=20 >>>> src/pkgbase/depend/mystuff/script1 >>>> src/pkgbase/depend/mystuff/textfile1 >>>> src/pkgbase/depend/mystuff/sourcefile.c >>>> src/pkgbase/depend/mystuff/Makefile >>>>=20 >>>> You are a developer. You want to ship a package that contains "script1= ", "textfile1", and "binary1" (which is compiled by saying "make" to turn "= sourcefile.c" into "binary1") >>>>=20 >>>> You want to ship 8 types of packages: >>>>=20 >>>> 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 >>>>=20 >>>> This is where my framework comes in-handy... >>>>=20 >>>> cd ~/src/pkgbase/freebsd/RELENG_4/category/mystuff >>>> make >>>> # it pulled the necessary bits from "src/pkgbase/depend/mystuff" and b= uilt the .tgz >>>>=20 >>>> cd ~/src/pkgbase/freebsd/RELENG_8/category/mystuff >>>> make >>>> # it pulled the necessary bits from the "depend" dir and built .tbz >>>>=20 >>>> cd ~/src/pkgbase/redhat/rhel4/category/sub-category/mystuff >>>> make >>>> # pulled in "depend" and made .rpm >>>>=20 >>>> cd ~/src/pkgbase/redhat/rhel6/category/sub-category/mystuff >>>> make >>>> # pulled in "depend" and made .rpm >>>>=20 >>>> etc. >>>>=20 >>>> Of course, *any* time the depend tree has binaries in it... you have t= o first 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 bin= aries. Once you've done that, you don't have to muck with the depend tree a= gain unless there are changes there. >>>>=20 >>>> So, I assume that your prejudice remarks are because you haven't eithe= r seen (a) such a platform or (b) such a need for said platform. >>>>=20 >>>> Yeah, I could rewrite the freebsd-specific logic to use "pkg create", = but let me tell you... >>>>=20 >>>> When you have to touch a file that needs to get shipped out to multipl= e platforms... >>>>=20 >>>> It's damned nice to be able to build the FreeBSD packages under RedHat= *BECAUSE* the redhat RPMs can't be built under anything else (building an = RPM on FreeBSD and attempting to install it on RedHat results in an error m= essage similar to "this is an rpm for FreeBSD; go away"). >>>>=20 >>>> Whereas FreeBSD will never balk about a package built on another platf= orm. >>>>=20 >>>> It's a huge time-saving measure... not having to jump over to each/eve= ry unique platform to package things up *IF/WHEN* you know that there are n= o binaries in the package *or* you've already checked the pre-compiled bina= ries into the arch-specific hierarchy. >>>>=20 >>>>=20 >>>>=20 >>>>=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= intention of using "pkg create". >>>=20 >>> You still haven't really explained at all why you can't use libpkg. If= it doesn't run on Debian (not tried), it's got to be easier to port it tha= n rewrite a hacked version, hasn't it??? At least then you'll also be cont= ributing back. >>>=20 >>=20 >> Simple, really. >>=20 >> Let's take RPM for example. The RPM package format has been ported to ot= her platforms. >>=20 >> But, I can't take archivers/rpm4 and build on RPM on FreeBSD and install= it on RedHat. >>=20 >> This is because the RPM format records the platform that you "build" you= r RPM on (not the binaries, just the RPM) *into* said RPM. >>=20 >> This actually adds a requirement to the RPM production that the RPMs be = produced on the platform that they will be installed-to. >>=20 >> Currently, no such restriction exists for the building of FreeBSD packag= es (within our system). This would have been true if we had ported pkg_crea= te (and may continue to be true if we ported pkg and its ilk), but let's sa= y for the sake of argument that the future of "pkg" looks bright and it get= s ported 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 (re= sulting in refusal to install a *.txz package because it was rolled on a di= fferent platform. >>=20 >> In that case, we'd then prefer to by-pass the tools and use our own meth= od of creating the tar-ball to lift such a restriction. >>=20 >> ASIDE: If I knew how to force rpmbuild into creating androgynous package= s for other architectures, I'd be doing that to life the restriction there = too, but I haven't figured out that. >>=20 >> Basically... within our "pkgbase" tree, we like the branch within the tr= ee to dictate how a package is built... not what platform you're on. The go= al being that we can run a single package-build host that builds all of our= packages from a single platform. >> -- >> Devin >>=20 >> _____________ >> The information contained in this message is proprietary and/or confiden= tial. If you are not the intended recipient, please: (i) delete the message= and all copies; (ii) do not disclose, distribute or use the message in any= manner; and (iii) notify the sender immediately. In addition, please be aw= are that any message addressed to our domain is subject to archiving and re= view by persons other than the intended recipient. Thank you. >> _______________________________________________ >> freebsd-current@freebsd.org mailing list >> https://urldefense.proofpoint.com/v1/url?u=3Dhttp://lists.freebsd.org/ma= ilman/listinfo/freebsd-current&k=3D%2FbkpAUdJWZuiTILCq%2FFnQg%3D%3D%0A&r=3D= Mrjs6vR4%2Faj2Ns9%2FssHJjg%3D%3D%0A&m=3D%2FFBYMopr3kmkYeXlwxBrUhJ1pMA6Fg3Fe= ekZ9VXWlQY%3D%0A&s=3D1db27aa85bccd5d393060e70ae8587478ba99da599264ca6515a66= 7c6acfccdd >> To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.or= g" _____________ 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.