Re: RFC: kernel abi handling/package series
On Thu, Jul 03, 2008 at 02:05:56PM +0200, Michael Vogt <mvogt@acm.org> was heard to say:
> I would like to ask for opinions on the problem of upgrading sets of
> packages which have multiple 'series' in the archive. The primary use
> case here is handling kernel upgrades and the kernel abi, but it
> equally applies to e. g. postgresql-8.1 vs. postgresql-8.3 and version
> specific extension packages.
Hi, Michael. This is an interesting problem to solve but I'm a little
unclear on the specifics of what you're proposing. Commentary below.
> This topic was discussed on a recent developer summit, and the current
> proposal has been written down as a specification [1]. It proposes to
> introduce a new relation field "Package-Series:" which groups related
> packages together and thus hints apt to do the right thing on upgrades
> without having to manually maintain metapackages, or forcing users to
> install a huge big driver package (such as linux-modules-...) although
> they only need one particular driver. A package-series behaves a bit
> like a task but it would enforce that all packages in a series get
> installed if there is a installed package already.
[snip]
> Apt would then look for the package series installed (a package series
> is considered installed if one package that declares this series is
> installed). Then it checks each package with a Pkg-Series header for
> the series that it wants to be part in. If all the series that it
> wants to be part in are installed on the system, then this package is
> marked for install.
This seems to be the meat of the design. I'm a little uneasy with the
vagueness of the semantics. Is this what you mean?
Right now our dependencies have the structure
A -> B \/ C \/ D ...
where A, B, ... each represent a package version [0], -> is logical
implication, and \/ is logical disjunction (OR). That is, one version
requires that one of a collection of other versions be installed. (I'm
leaving aside Conflicts for now)
It sounds to me like what you're proposing is to add a new type of
"joint dependency" with the form
A /\ B -> B \/ C \/ D ...
and to have this dependency be "weak", like Recommends are. So it
would be enforced when it first appeared or when its left-hand side
changed from "false" to "true". A pair of declarations of the form
A_1 Pkg-Series: series, B_1
A_2 Pkg-Series: series, B_2
has the effect of introducing joint dependencies
A_1 /\ B_2 -> A_2
A_2 /\ B_1 -> A_1
that is, A_1 and B_2 jointly recommend A_2 and vice versa. More
generally, if you have
A_i Pkg-Series: series, B_i for 0 < i <= n
you get n * (n-1) joint dependencies,
A_i /\ B_j for 0 < i,j <= n and i != j
I offer this mostly as a way of understanding what package series are
supposed to mean. I don't think we want to directly represent the joint
dependencies they are equivalent to, because (a) there are n^2 of them,
and (b) the whole point is that A_1 doesn't have to know about A_2 in
order to get a dependency on it. If this is what you mean, then I think
it seems reasonable and it's no problem to support it in aptitude.
[0] technically propositional variables that indicate whether the
version is installed.
> Given the complexity that the outlined solution has, we are
> interessted in alternative ideas too. One possible alternative idea
> was to add plugin support to libapt so that external plugin libraries
> could hook into certain bits of apt (e.g. the MarkInstall() call in
> pkgDepCache) to provide special resolving functionality. Then we could
> add new headers like "Kernel-Driver: foo", "Kernel-ABI: 2.6.25-2-686"
> and write a custom kernel-abi plugin for this. Of course c++ and
> plugin is a challange in itself too :)
That doesn't sound like a way to *reduce* complexity to me.
I think your approach seems fairly simple, or at least it did once I
hit on the idea of explaining it using implicit joint dependencies.
Daniel
Reply to: