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

[Richard Hughes]

On 01/09/2007, Tom Parker <palfrey at tevp.net> wrote:
> Richard Hughes wrote:
> >> * "Conflicts" - "Won't work with that package"
> > Hmm, I'm not sure conflicts are a good idea in /any/ packaging system.
>
> Major use of conflicts is for making sure that old versions of
> particular packages aren't installed. For example, the lyx package used
> to be just the core stuff, and depend on either lyx-qt or lyx-xforms for
> the main package. Now, lyx-xforms has been dropped and lyx-qt is the
> only interface packaged, but that's been folded into the main lyx
> package. Therefore, the new lyx package conflicts on both lyx-qt and
> lyx-xforms.

Sure.

> The other is for virtual packages (e.g. mail-transport-agent). Any
> package that has the relevant functionality has a "Provides" line, and
> will often (in the case of things like MTAs where there should only
> really be one on a system) both have Conflicts and Replaces on the
> virtual functionality (I'm reading directly from the Debian Policy
> Manual, Section 7.5.2
> http://www.debian.org/doc/debian-policy/ch-relationships.html)

Huh, if I don't understand this then poor users havn't got a chance.
What about just aborting the install if there are conflicts? "Exim
cannot be installed until sendmail was been removed"

> >> * "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.
>
> See above for why it's there. Also, things like "we're moving a file
> from one package into another" e.g. something that was in foo gets moved
> to foo-common (a dependancy of foo). As replacing files is normally a
> fault in the package, allowing foo-common to replace *only* things in
> foo allows a foo-common upgrade without necessarily needing a foo
> upgrade. Depends on exactly how tightly bound the two are. It's a bit
> hacky, but it seems to work ok.

Sure, the backend should do the right thing. Seriously, I don't want
to know this sort of detail, I just want to install stuff like httpd
and gaim and update my system. If we have to explain about how
conflicts and obsoletes works to a user then we've lost 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.
>
> There are cases where "correct" dependancy resolution isn't possible
> without user input. For example, at some point I wanted to upgrade the
> libgtk2.0 package, and it conflicted with existing versions of certain
> libraries (until they got rebuilt properly and got higher version
> numbers), including one that the Gimp relied on. Now, in this case, the
> libgtk upgrade was non-vital, so I put it off until said library got
> rebuilt. But imagine I wanted to install a new package (WizzyBar) that
> relied on that upgraded libgtk2.0.. then we've got a choice: do we
> install WizzyBar and lose the Gimp, or do we tell the user to get stuffed?

We should never remove packages to satisfy a dep. If wizzybar depended
on libraries not compatible with gimp, then we fail, and let the
distro sort it out on the next push. The user shouldn't have to
choose, no matter how buggered the repo is.

> There are cases where the software simply can't know what's the "right"
> thing to do, and the user then needs to be given the choice. These
> things tend to get resolved by the time a package makes it to Debian's
> stable (or mainly by the time it hits "testing"), but "unstable" gets
> these on a more frequent basis, and as I'd rather not be still using
> Gnome 2.14, "unstable" (which despite the name and these complaints,
> isn't that bad) is a common choice.

I don't think this belongs in the UI, we need to keep it simple and
effective. Remember, power user still have aptitude and yum on the
command line, PackageKit should focus on the "I don't care how it
works just do it" technical challenge.

Richard.