>>>>> "dm" == David Magda <dma...@ee.ryerson.ca> writes: >>>>> "bf" == Bob Friesenhahn <bfrie...@simple.dallas.tx.us> writes:
dm> OP may also want to look into the multi-platform pkgsrc for
dm> third-party open source software:
+1. jucr.opensolaris.org seems to be based on RPM which is totally
fail. RPM is the oldest, crappiest, most frustrating thing! packages
are always frustrating but pkgsrc is designed to isolate itself from
the idiosyncracies of each host platform, through factoring.
Its major weakness is upgrades, but with Solaris you can use zones and
snapshots to make this a lot less painful:
* run their ``bulk build'' inside a zone. The ``bulk build'' feature
is like the jucr: it downloads stuff from all over the internet and
bulids it, generates a tree of static web pages to report its
results, plus a repository of binary packages. Like jucr it does
not build packages on an ordinary machine, but in a well-specified
minimal environment which has installed only the packages named as
build dependencies---between each package build the bulk scripts
remove all not-needed packages. Thus you really need a separate
machine, like a zone, for bulk building. There is a non-bulk way
to build pkgsrc, but it's not as good.
Except that unlike the jucr, the implementation of the bulk build
is included in the pkgsrc distribution and supported and ordinary
people who run pkgsrc are expected to use it themselves.
* clone a zone, upgrade the packages inside it using the binary
packages produced by the bulk build, and cut services over to the
clone only after everything's working right.
Both of these things are a bit painful with pkgsrc on normal systems
and much easier with zones and ZFS. The type of upgrade that's
guaranteed to work on pkgsrc, is:
* to take a snapshot of /usr/pkgsrc which *is* pkgsrc, all packages'
build instructions, and no binaries under this tree
* ``bulk build''
* replace all your current running packages with the new binary
packages in the repository the bulk build made.
In practice people usually rebuild less than that to upgrade a
package, and it often works anyway, but if it doesn't work then you're
left wondering ``is pkgsrc just broken again, or will a more thorough
upgrade actually work?''
The coolest immediate trick is that you can run more than one bulk
build with different starting options, ex SunPro vs gcc, 32 vs 64-bit.
The first step of using pkgsrc is to ``bootstrap'' it, and during
bootstrap you choose the C compiler and also whether to use host's or
pkgsrc's versions of things like perl and pax and awk.
You also choose prefixes for /usr /var and /etc and /var/db/pkg that
will isolate all pkgsrc files from the rest of the system. In general
this level of pathname flexibility is only achievable at build time,
so only a source-based package system can pull off this trick. The
corrolary is that you can install more than one pkgsrc on a single
system and choose between them with PATH. pkgsrc is generally
designed to embed full pathnames of its shared libs, so this has got a
good shot of working.
You could have /usr/pkg64 and /usr/pkg32, or /usr/pkg-gcc and
/usr/pkg-spro. pkgsrc will also build pkg_add, pkg_info, u.s.w. under
/usr/pkg-gcc/bin which will point to /var/db/pkg-gcc or whatever to
track what's installed, so you can have more than one pkg_add on a
single system pointing to different sets of directories. You could
also do weirder things like use different paths every time you do a
bulk build, like /usr/pkg-20100130 and /usr/pkg-20100408, although
it's very strange to do that so far.
It would also be possible to use ugly post-Unix directory layouts, ex
/pkg/<marker>/usr/bin and /pkg/<marker>/etc and
/pkg/<marker>/var/db/pkg, and then make /pkg/<marker> into a ZFS that
could be snapshotted and rolled back. It is odd in pkgsrc world to
put /var/db/pkg tracking-database of what's installed into the same
subtree as the installed stuff itself, but in the context of ZFS it
makes sense to do that. However the pathnames will be fixed for a
given set of binary packages, so whatever you do with the ZFS the
results of bulk builds sharing a common ``bootstrap'' phase would have
to stay mounted on the same directory. You cannot clone something to
a new directory then add/remove packages. There was an attempt called
``pkgviews'' to do something like this, but I think it's ultimately
doomed because the idea's not compartmentalized enough to work with
every package.
In general pkgsrc gives you a toolkit for dealing with suboptimal
package trees where a lot of shit is broken. It's well-adapted to the
ugly modern way we run Unixes, sealed, with only web facing the users,
because you can dedicate an entire bulk build to one user-facing app.
If you have an app that needs a one-line change to openldap, pkgsrc
makes it easy to perform this 1-line change and rebuild 100
interdependent packages linked to your mutant library, culminating in
your app's package, and partition all of it inside
/usr/pkg-weirdapp/bin and /etc/pkg-weirdapp and /var/pkg-weirdapp
while the rest of the system uses the normal ldap library. IPS
repositories will always have fixed install paths because most of
these things are only easy to set at build time.
Developing packages with pkgtool/rpm is really unpleasant. Here are
some things pkgsrc does for me that pkgtool won't:
* I had to learn you must incant '-lldap_r-2.4 -llber-2.4' whenever
you want to use ``real'' LDAP client on Solaris, and nonsense has
to go inside every single ``spec'' file.
With pkgsrc there is a ``buildlink'' framework for ldap. If a host
OS is weird, like Solaris, ``buildlink'' will make it look normal,
quietly adding -L<blah> symlink spaghetti to either make the modern
Solaris libs appear under the plain -lldap names without any -2.4
garbage, or else build openldap from pkgsrc and point to the local
copy.
I will have to learn how to use LDAP properly within pkgsrc,
regardless of what is my host platform. But if i were using
pkgsrc, I probably wouldn't even know about the -lldap_r-2.4
-llber-2.4 stupidity. Life is too short for this garbage. And when
Solaris finally undoes the ldap crazy, you can fix it in one place
in the pkgsrc framework instead of having to undo ad-hoc patches in
1000 .spec files.
* If you want to patch a configure.in or Makefile.in under pkgsrc,
there are macros to rerun autoconf, automake, and libtool. You can
ask for specific versions of any of them, and they'll be
automatically built for you. Anything a package builder does all
the time is factored out like this and becomes a single line in the
package Makefile expressing what you want. And no one ever patches
a 'configure' script itself. That's painful garbage, and the patch
can't be submitted upstream so it's wasted work of the packager.
We only patch the .in files and then wave a hand and say ``rebuild
it''.
* When you are developing a RPM/pkgbuild package, over and over you
say 'pkgtool build-only', and the stupid thing rm -rf's the build
tree and starts over. pkgsrc is Makefile-based, and will start
from where it left off. You can hit ^C, change something, and
restart the build even, just like normal software development. Of
course bulk builds do not work this way, but pkgsrc understand a
tight development cycle is needed for the developers of packages,
and this enforced clean, a, b, c, PANIC shit is no good when you
are invoking the tool from the command line.
There is even some imperfect provision within buildlink for running
binaries from the not-installed build directory and having them
pull in shared libs from other build directories inside pkgsrc
instead of from /usr/pkg/lib, but IMHO this kind of thing is doomed
and silly in the long run, and build dependencies should be fully
installed inside the development zone.
There are actually a lot of things gentoo does better than pkgsrc
IMHO, but then pkgsrc bulk builds are smarter about the hidden
dependency problem, and about marking whether two different versioned
packages are binary-compatible or only source-compatible with each
other. Neither one's perfect, but I'll take either one over
RPM-derived straightjacketed chaos.
and like I said ZFS+zones help with lots of what I hated about pkgsrc
before (to make this a little more OT). Clonable filesystems and
lightweight zones are real revolution-makers for packaging tools, and
are the main reason I think source-based package systems have the
strongest future. It is really possible, if you feel like it, to
rebuild from source everything linked to libpng just to fix a small
security bug in libpng, then push out the result with something
rsync-ish, and maybe even install the result atomically, and it is
cheaper to do this kind of thing than drive yourself blind with manual
regression tests. Most of the time in a bulk build is spent
installing and uninstalling packages, but with some clever AI the bulk
build framework could map out the entire process and mark off certain
nodes of the dependency graph which are unusually dense, and take
snapshots of a filesystem with that set of packages installed which it
coudl start with, then install or uninstall a few packages to reach
the exact set specified by the build dependencies. This could make it
possible to finish a lot more bulk builds per day.
The type of regression tests the developers of big messy things like
X11 and GNOME really need are the sort you can only do with an
autobuild cluster, so I really think this is the way forward.
bf> But this does not update the OS kernel. It is for application
bf> packages. I did have to apply a source patch to the FreeBSD
bf> kernel the last time around.
yes, well, that is why it works on Solaris at all. It has nothing to
do with kernels, and starts from the quaint and ancient tradition that
any unix system will provide some form of basically standard
application development environment. It's a userland package system
that works on a variety of ``less equal'' operating systems. Of
course it will not take over anything outside itself like kernels.
and it's not part of FreeBSD at all. It will run there, but you may
as well use ports instead on FreeBSD because a lot more packages will
be working properly then. pkgsrc is used on NetBSD, DragonFly, Mac OS
X, u.s.w.
pgpXZoG9o41N0.pgp
Description: PGP signature
_______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
