... 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.te...@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 >>> "sourcefile.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 built >>> 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 >>> binaries. Once you've done that, you don't have to muck with the depend >>> tree again 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", but >>> 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 >>> RPM on FreeBSD and attempting to install it on RedHat results in an error >>> message similar to "this is an rpm for FreeBSD; go away"). >>> >>> Whereas FreeBSD will never balk about a package built on another platform. >>> >>> It's a huge time-saving measure... not having to jump over to each/every >>> 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 >>> binaries 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 >> contributing back. >> > > Simple, really. > > Let's take RPM for example. The RPM package format has been ported to other > 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 > produced on the platform that they will be installed-to. > > 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 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 (resulting in > refusal to install a *.txz package because it was rolled on a different > platform. > > 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. > > 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 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 packages > from a single platform. > -- > Devin > > _____________ > The information contained in this message is proprietary and/or confidential. > 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 aware that > any message addressed to our domain is subject to archiving and review 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-unsubscr...@freebsd.org" _______________________________________________ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
