From owner-freebsd-current@FreeBSD.ORG Sun Jul 14 18:50:52 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 47D16EF; Sun, 14 Jul 2013 18:50:52 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-wg0-x22e.google.com (mail-wg0-x22e.google.com [IPv6:2a00:1450:400c:c00::22e]) by mx1.freebsd.org (Postfix) with ESMTP id A92DDDAE; Sun, 14 Jul 2013 18:50:51 +0000 (UTC) Received: by mail-wg0-f46.google.com with SMTP id c11so9484472wgh.25 for ; Sun, 14 Jul 2013 11:50:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=rEMtkD2+uQa2qHleGUJe9hgWejD8mTNX9mCHmwjAtGg=; b=cEzzPCsuHN815OaZbIhc/GzF6AdtjMY2UAqLis89FoCST3mZkzEFTeKL0FbuZm5YqU Ee4Wnz5IvWgzW6mzjGkJ0AOom+H5715Og+24lAahVg5GuFNxLIxh5dU0fRKGGrvZ2X1S SlejZmZpLRvim4/1/xPlNU0Y802sxYIB8hhrfm7VTYjLLcKNx0jf1OrA6Bn1xf94FL0h eneC7Pm41ZCcO/PgIGdaVjAPXdGjuz+Y9dKxNYDMWFJeKL6LKVBYAYclH9bNSGei30HV yPtBTXpu+gEJmeDKF5xP1o2IBUnc+0C+Usqmgl2FqFaU6Zd8MlVzDNkazJZPAkBKzKpj rmww== MIME-Version: 1.0 X-Received: by 10.180.82.196 with SMTP id k4mr6909652wiy.0.1373827850604; Sun, 14 Jul 2013 11:50:50 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.217.94.132 with HTTP; Sun, 14 Jul 2013 11:50:50 -0700 (PDT) In-Reply-To: <13CA24D6AB415D428143D44749F57D7201FC59E8@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> Date: Sun, 14 Jul 2013 11:50:50 -0700 X-Google-Sender-Auth: BOGo47ChSdnpezy3uOqhoI38xT0 Message-ID: Subject: Re: [HEADSUP] No more pkg_install on HEAD by default From: Adrian Chadd To: Devin Teske Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Chris Rees , "freebsd-current@freebsd.org" , Garrett Wollman X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list 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 18:50:52 -0000 ... 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. -adrian On 14 July 2013 09:52, Teske, Devin wrote: > > On Jul 14, 2013, at 8:01 AM, Chris Rees wrote: > >> On 14 Jul 2013, at 08:29, Teske, Devin wrote: >>> >>> 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"= , "textfile1", and "binary1" (which is compiled by saying "make" to turn "s= ourcefile.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 bu= ilt 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= 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 bina= ries. Once you've done that, you don't have to muck with the depend tree ag= ain unless there are changes there. >>> >>> So, I assume that your prejudice remarks are because you haven't either= seen (a) such a platform or (b) such a need for said platform. >>> >>> Yeah, I could rewrite the freebsd-specific logic to use "pkg create", b= ut let me tell you... >>> >>> When you have to touch a file that needs to get shipped out to multiple= platforms... >>> >>> 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 R= PM on FreeBSD and attempting to install it on RedHat results in an error me= ssage similar to "this is an rpm for FreeBSD; go away"). >>> >>> Whereas FreeBSD will never balk about a package built on another platfo= rm. >>> >>> It's a huge time-saving measure... not having to jump over to each/ever= y unique platform to package things up *IF/WHEN* you know that there are no= binaries in the package *or* you've already checked the pre-compiled binar= ies 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. >>>> >>> >>> >>> I have no intention of making old-world packages... but I also have no = intention of using "pkg create". >> >> 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 than= rewrite a hacked version, hasn't it??? At least then you'll also be contr= ibuting back. >> > > Simple, really. > > Let's take RPM for example. The RPM package format has been ported to oth= er platforms. > > But, I can't take archivers/rpm4 and build on RPM on FreeBSD and install = it on RedHat. > > This is because the RPM format records the platform that you "build" your= RPM on (not the binaries, just the RPM) *into* said RPM. > > This actually adds a requirement to the RPM production that the RPMs be p= roduced on the platform that they will be installed-to. > > Currently, no such restriction exists for the building of FreeBSD package= s (within our system). This would have been true if we had ported pkg_creat= e (and may continue to be true if we ported pkg and its ilk), but let's say= for the sake of argument that the future of "pkg" looks bright and it gets= 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 (res= ulting in refusal to install a *.txz package because it was rolled on a dif= ferent platform. > > In that case, we'd then prefer to by-pass the tools and use our own metho= d of creating the tar-ball to lift such a restriction. > > ASIDE: If I knew how to force rpmbuild into creating androgynous packages= for other architectures, I'd be doing that to life the restriction there t= oo, but I haven't figured out that. > > Basically... within our "pkgbase" tree, we like the branch within the tre= e to dictate how a package is built... not what platform you're on. The goa= l being that we can run a single package-build host that builds all of our = packages from a single platform. > -- > Devin > > _____________ > The information contained in this message is proprietary and/or confident= ial. 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 awa= re that any message addressed to our domain is subject to archiving and rev= iew by persons other than the intended recipient. Thank you. > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org= "