[packagekit] Semantic issues with GetDeps (and other interface functions)
hughsient at gmail.com
Fri Aug 31 17:14:09 PDT 2007
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)
> 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).
> 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
> 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
> 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.
More information about the PackageKit