Re: handling derived packages
Brian Craft <bcboy@thecraftstudio.com> writes:
> Is there any precedent for handling derived packages? By "derived" I
> mean the package can't be put in an apt repository somewhere, but
> must be built on-the-fly. Here's an example.
Like all the kernel module sources that need to match the running kernel.
> Package "bar" must be derived. The package builder might be put in a
> package "foo". If "bar" depends on "foo", I believe apt will try to
> download "foo" and "bar", but "bar" doesn't actually exist until "foo"
> has been downloaded and configured. Also, apt won't know where "bar"
> is after it's created, so "foo" will have to set up a local disc
> repository, or drop the file in the cache or something.
If bar depends on foo nothing happens since bar does not yet
exist. Only after installing foo would there be an bar to install at
all. Or not?
> So... instead of using an explicit dependency "foo" could, perhaps,
> generate "bar" during foo.postinst, and then invoke apt-get or dpkg. But
> it seems pretty dicey to invoke the installer from the installer.
You can't invoke apt or dpkg since their lockfile is already
locked. You would have to delay the apt/dpkg call, which is very ugly,
or tell the admin to dpkg -i the package manually, also very
ugly.
Compiling the package on the fly and then installing in
/usr/lib/package/build (or something) is easier. You have to take care
of cleaning up and updating that though, esspecialy undoing a compile
if the postinst fails/gets interrupted at some point.
> Has anyone dealt with this issue? I've seen some jre wrapper packages,
> but they merely install the files outside the package system (so dpkg
> doesn't actually know about any of the installed files), rather than
> packaging the files and then installing them.
>
> b.c.
I'm working on support for this kind of things, actualy support for
custom kernel-image and module packages that are automatically build
whenever source changes as well as generally custom optimized debs.
The setup needs several general packages:
- sourcerer-archive
Manages a local apt-get'able archive via reprepro.
- sourcerer-buildd
Install a build environment and provides the build facilities, cron
jobs, niceness level, ...
- sourcerer-watcher
Installs hoocks into apt to watch for updates and such. Any updates
will be queued for the sourcerer-buildd.
And then you can provide some specific packages:
- bar-builder
Configure files for sourcerer-watcher and sourcerer-archive telling
them about foobar. Once this is installed and sourcerer-buildd has
been run a local flavour of 'bar' will be available for apt-get.
- bar-remote
Dummy package to say that bar-builder is installed on another host
and to point apt there for bar.
All of this would take care of updates for you. The remaining problem
is the first install. You have to get users to install bar-builder,
trigger the buildd (or wait) and then install bar.
Your foo package could "Depends: bar-builder | bar-remote" and contain
a wraper that installs bar on the first run if uninstalled or outputs
a meaningfull error message saying "apt-get install bar".
MfG
Goswin
Reply to: