Date: Wed, 3 Dec 2008 22:02:33 +0100 From: Peter Schuller <peter.schuller@infidyne.com> To: freebsd-ports@freebsd.org Subject: Deterministic package building with ports Message-ID: <20081203210233.GA55633@hyperion.scode.org>
next in thread | raw e-mail | index | archive | help
--2oS5YaxWCcQjTEyO
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
Hello,
I have been in a perpetual multi-year struggle to sort out package
building in a way which is practical for me. For the past half year or
so I have ended up using a hacked together shell script which does
approximately what I need, which is:
To build deterministically as a function of
(a) base system
(b) /etc/make.conf
(c) /usr/local/etc/ports.conf (sysutils/portconf)
(d) a list of specifically desired origins/packages which is manually
mainteined (NOT a complete list of dependencies, this is critical)
(e) the ports tree
a set of packages for later installation on another system
(typically the host system or other jails).
I build them in a dedicated package building jail, and can then either
just "pkg_add *.tbz" or use a hacked script which sort of ends up
doing the same, but differently.
This has *sort* of worked, but not quite. I am fairly close now to
have something that works, but am running into determinism issues. For
example, the dependencies of audio/aumix is a function of what happens
to already be built on the system. So initially when my script wants
to build audio/aumix, it happens to be the case that no X stuff has
been brought in yet, so 'make package-name' returns aumix-x.y.z. Later
on when aumix is picked up as a dependency as part of building
something else, 'make package-name' returns aumix-gtk-x.y.z. This
causes confusion because the tool thinks the "origin"[1] audio/aumix
has not been installed on the system.
Is it the intent of the design of ports that the behavior of packages
be implicitly dependent on the state of installed packages?
If the answer is no, is there active interest in trying to fix any
outstanding issues with respect to non-detemrinism that would allow
people to write package managers that do things that depend on
this[2]?
If the answer is yes, can someone suggest a practically viable that
consistently works, method of building binary packages under the above
conditions?
(I know of portupgrade/portmaster of course. I have never found a tool
that both (1) does what I want and (2) actually works
consistently. tinderbox I presume works, being used for official bulk
builds if I am not mistaken, but it is *hugely* too administratively
heavy/complex to set up just to be able to keep a system up-to-date!
Have I just completely missed the existence of a silver-bullet
solution that everyone is using?)
[1] What is a proper term here? I have not come up with anything
better, given that "package" is often interpreted as "binary package
file".
[2] I ran into the exact same problem with pkgsrc when writing pkgmanager,
and I see no way to do what I want without having the relevant
packaging system change. I need/want to perform higher-level
operations on the packaging system, without having to work around
specific issues that are a function of the exact details of the
makefiles. Things I want to be determinstic include the plist, the
list of dependencies, the package name, and the distfiles required.
--=20
/ Peter Schuller
PGP userID: 0xE9758B7D or 'Peter Schuller <peter.schuller@infidyne.com>'
Key retrieval: Send an E-Mail to getpgpkey@scode.org
E-Mail: peter.schuller@infidyne.com Web: http://www.scode.org
--2oS5YaxWCcQjTEyO
Content-Type: application/pgp-signature
Content-Disposition: inline
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (FreeBSD)
iEYEARECAAYFAkk28+kACgkQDNor2+l1i3280ACfe7ZpDHBMXz6jxsfOa8GZ52fO
08gAn3czD7uN0xN/bLvHasZTb+xOtPdM
=8rAi
-----END PGP SIGNATURE-----
--2oS5YaxWCcQjTEyO--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20081203210233.GA55633>