... 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_at_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_at_freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe_at_freebsd.org"Received on Sun Jul 14 2013 - 16:50:52 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:39 UTC