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

[Tom Parker]

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.

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)

>> * "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.

>> 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?

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.

Tom