Date: Sun, 14 Jul 2013 11:50:50 -0700 From: Adrian Chadd <adrian@freebsd.org> To: Devin Teske <dteske@freebsd.org> Cc: Chris Rees <crees@bayofrum.net>, "freebsd-current@freebsd.org" <freebsd-current@freebsd.org>, Garrett Wollman <wollman@hergotha.csail.mit.edu> Subject: Re: [HEADSUP] No more pkg_install on HEAD by default Message-ID: <CAJ-VmomBya3arWpbDPm4zxXaRvykkPUudrN_DxisMBCn75B58w@mail.gmail.com> In-Reply-To: <13CA24D6AB415D428143D44749F57D7201FC59E8@ltcfiswmsgmb21> References: <20130712231637.GS85556@ithaqua.etoilebsd.net> <13CA24D6AB415D428143D44749F57D7201FC2DBD@ltcfiswmsgmb21> <20130713080732.GV85556@ithaqua.etoilebsd.net> <13CA24D6AB415D428143D44749F57D7201FC3AA2@ltcfiswmsgmb21> <13CA24D6AB415D428143D44749F57D7201FC3C92@ltcfiswmsgmb21> <CA%2B7WWSe7C2UXAsEX3OZH7nPJJbxotpQ_iYBxgake4R68sbUtLA@mail.gmail.com> <13CA24D6AB415D428143D44749F57D7201FC3FAA@ltcfiswmsgmb21> <CAGE5yCoH2auer_kKpUT_caFUZPpVM5TdAFH5tJcGgF4Ji12f0g@mail.gmail.com> <201307140613.r6E6Dsov002016@hergotha.csail.mit.edu> <201307140706.r6E76Kg0002959@hergotha.csail.mit.edu> <13CA24D6AB415D428143D44749F57D7201FC51FE@ltcfiswmsgmb21> <7325EE70-8821-4350-9D8A-E5CAAC548FE9@bayofrum.net> <13CA24D6AB415D428143D44749F57D7201FC59E8@ltcfiswmsgmb21>
next in thread | previous in thread | raw e-mail | index | archive | help
... 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 <Devin.Teske@fisglobal.com> 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= "
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAJ-VmomBya3arWpbDPm4zxXaRvykkPUudrN_DxisMBCn75B58w>