Re: Shepherd in Debian

[Rob Browning <rlb@defaultvalue.org>]

Vagrant Cascadian <vagrant@debian.org> writes:

> To avoid noise like that, it may require rebuilding the package, and the
> usual detection mechanisms in Debian for things that require rebuilds
> (e.g. ABI bumps in C libraries) do not appear to trigger in any way with
> guile packages.

While I haven't thought hard about this with respect to Guile yet, and
even ignoring anything involving per-architecture binary ABIs
(i.e. per-arch shared libs), I suspect the problem is "reasonably
difficult", (though note that I'm mostly speaking here from a Debian
perspective, and based on similar experiences with Emacs), and I would
be very happy to be wrong.

One option, of course, is to just omit .go files from "add on" (Guile
dependent) packages, and let autocompilation (per user) handle
everything.  This is expensive (and who cleans up, when?), but
side-steps a lot of other issues.

For Guile at least, you could also ship a full set of .go files in each
package (i.e. all four size and endianness combinations) with the
attendant size increases, but I believe this may be insufficient, even
if you were to include the "go-ABI" in the package dependencies (which
would require either versioned Guile packages per go-ABI change[1], or
"flag days" in unstable whenever the go-ABI changes).

It may be insufficient unless every add-on package carefully versions
its Scheme API, and remembers to include relevant changes to any of its
public macros as part of of that API, because of course macro changes
could require rebuilding all of the package's reverse dependencies.

Alternately, instead of shipping go files, you could decide to just
build/rebuild/remove them during package installation/removal for the
installed Guile versions (guile-X.Ys), and Debian's Emacs policy tries
to for emacsen, but that's also fraught (in Debian at least), given what
the install/remove/upgrade maintainer script invocations allow[2].

A potential additional problem this approach creates is that you might
want have just one "add on" package, say guile-foo, work with multiple
Guile versions (guile-3.1, guile-3.2, etc. as Emacs policy does), but
then guile-foo *and* all of its guile-related reverse dependencies need
to be rebuilt/removed for a given Guile "flavor" opportunistically,
whenever any guile-X.Y is installed/upgraded/removed.

And *that* raises the bar substantially (again in Debian, at least),
because of [2] coupled with the fact that you might need to run the
rebuilds/removals in proper inter-package dependency order (unless
upstream has sufficient built-in tooling for that) outside the normal
apt/dpkg process.

And since any given apt/dpkg run could be installing or removing various
things, including guile-X.Y flavors in the same run with add-on package
(e.g. guile-foo) installs/removals/upgrades, "it's complicated".

[1] ...which Debian already has via the guile-X.Y versioning, *if* Guile
    never changes the ABI in a Z version.

[2] The current Emacs policy is broken, and coming up with a fix has
    been difficult.  The problem arose when we realized that (roughly)
    the only places *Debian* policy says you can count on your
    dependencies being available/ready are in your "postinst configure
    ..."  and your "postinst triggered ..." (and it appears that
    triggers don't promise any ordering wrt deps).  So, for example, you
    can't rely on anything outside your package or the Debian base tools
    (perl-base, ...) to clean up (in the preinst/prerm/postrm).

    Debian's current Emacs policy, had assumed (and requires) add-on
    packages to depend on and make calls to emacsen-common package tools
    from their prerm, for example, and that can (and as we saw, does)
    just break sometimes when emacsen-common, dependency or not, isn't
    properly installed.

> There was a big change in Debian recently where guile was downgraded
> from 3.10.x back to 3.9.x. That was a little bit exciting.

Right, we had do do that because 3.0.10 was just broken on 32-bit
architectures.  I'm hoping we'll have a 3.0.11 we can move to for
trixie.

Thanks, and I hope I'm just wrong somehow regarding the complexity here.
-- 
Rob Browning
rlb @defaultvalue.org and @debian.org
GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0 39E9 ED1B 597A
GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4