Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 14 Jul 2013 16:52:26 +0000
From:      "Teske, Devin" <Devin.Teske@fisglobal.com>
To:        Chris Rees <crees@bayofrum.net>
Cc:        Devin Teske <dteske@freebsd.org>, Garrett Wollman <wollman@hergotha.csail.mit.edu>, "freebsd-current@freebsd.org" <freebsd-current@freebsd.org>
Subject:   Re: [HEADSUP] No more pkg_install on HEAD by default
Message-ID:  <13CA24D6AB415D428143D44749F57D7201FC59E8@ltcfiswmsgmb21>
In-Reply-To: <7325EE70-8821-4350-9D8A-E5CAAC548FE9@bayofrum.net>
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>

next in thread | previous in thread | raw e-mail | index | archive | help

On Jul 14, 2013, at 8:01 AM, Chris Rees wrote:

> 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 "so=
urcefile.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 bui=
lt 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 to =
first do a make in there on the platform you want to ship the binary for, a=
nd then do "make depend" in the platform-specific tree to pull in the binar=
ies. Once you've done that, you don't have to muck with the depend tree aga=
in unless there are changes there.
>>=20
>> 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.
>>=20
>> Yeah, I could rewrite the freebsd-specific logic to use "pkg create", bu=
t let me tell you...
>>=20
>> When you have to touch a file that needs to get shipped out to multiple =
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 RP=
M on FreeBSD and attempting to install it on RedHat results in an error mes=
sage similar to "this is an rpm for FreeBSD; go away").
>>=20
>> Whereas FreeBSD will never balk about a package built on another platfor=
m.
>>=20
>> 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 binari=
es 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 i=
ntention of using "pkg create".
>=20
> You still haven't really explained at all why you can't use libpkg.  If i=
t 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 contri=
buting back.
>=20

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 R=
PM on (not the binaries, just the RPM) *into* said RPM.

This actually adds a requirement to the RPM production that the RPMs be pro=
duced 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 f=
or the sake of argument that the future of "pkg" looks bright and it gets p=
orted 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 (resul=
ting in refusal to install a *.txz package because it was rolled on a diffe=
rent 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 f=
or 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 pa=
ckages from a single platform.
--=20
Devin

_____________
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.



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?13CA24D6AB415D428143D44749F57D7201FC59E8>