[packagekit] Semantic issues with GetDeps (and other interface functions)

[Richard Hughes]

On 31/08/2007, Tom Parker <palfrey at tevp.net> wrote:
> Summary: Giving a simple package_id-specified list of dependencies is
> non-trivial (plus other interface semantic issues)

Yes, agreed. We need to sort this to "most sane" IMO, see below.

> Got a problem while thinking about how to build GetDeps. For .deb's, we
> can have many "dependancies". Some are "Depends", but then we've got
>
> * "Pre-Depends" - like Depends, but IIRC is more of a hint to the setup
> bits to do the *whole* process for Pre-Depends packages before starting
> to install this package.

Sure, understood. I guess dpkg or intltool would be a good example for
this. In my book this is a hard dep.

> * "Suggests" - "You probably want this package"
> * "Recommends" - "Adding this package will help"

Hmm.Do we want to add a boolean flag b=force to the getdeps method?

> * "Conflicts" - "Won't work with that package"

Hmm, I'm not sure conflicts are a good idea in /any/ packaging system.

> * "Replaces" - "Both can be installed at the same time, but only if you
> do this one this second and it'll override some stuff that the other one
> would normally do"

Umph, thats sortof cracktastic in my book.

> (Some of that might be a bit off, need to re-read the Debian Packaging
> Policy document, but you get the idea)

Sure.

> Oh, and then they're all potentially versioned ("This applies to all
> versions equal to, less than, greater than, etc") and there can be many
> options ("You need at least one of these"), so a single
> Depends/Suggests/etc may give you a list of packages (especially once we
> get into funny business like virtual packages).

Sure.

> I have no idea how much this sort of thing happens with rpm's or any
> other package formats, but I don't have any bright ideas offhand about
> how to fix this.

rpm's cannot conflict, which makes life a little easier IMO.

> Current versions of aptitude (my current package
> management frontend of choice) actually give you multiple options for
> resolving dependencies, which may well include removing or upgrading
> various packages. It's even got a nifty little points scheme for giving
> you in turn the sets of changes that will change your system the least.

That sounds pretty wack. What I want to know is:

"I want to install OpenOffice. What else do I need to install to get it working"

So I would argue all suggests and recommended packages fall into that
quite naturally.

> Other related issues: should searches provide only one version of a
> named package?

No, I think it can return multiple. At least with conary we can get
multiple versions for the same search.

> My system (admittedly I've gone a bit overboard with the
> apt-pinning) can end up with 4 or more versions of particular packages,
> all with differing dependencies (and potentially *slightly* different
> descriptions).

Sure.

> Something else: Are the searches case dependant?

Good question. I would say always no.

> I think that's everything I can think of offhand, but I'm sure more
> thoughts will come to mind.

Good ideas. I always knew we would find finding common ground
difficult, but I think we've got the right guys on the job to get a
pretty good technical solution.

Richard.