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

[Tim Lauridsen]

Richard Hughes wrote:
> 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.
> _______________________________________________
> PackageKit mailing list
> PackageKit at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/packagekit
>   
+1.
We need to keep it safe, if the backend can't perform the action without 
user choices, then it should fail.
By the way, rpm also contains conflict and obsoletes.
if foo has conflict bar, foo can't be installed if bar is already 
install, but yum will just report an error not solve the error. (because 
it cant be done in a safe way)
if foo obsoletes bar then bar will be bar will be removed when foo is 
install (typicaly use with packages changing name ex. gaim -> pidgin)

Tim

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/packagekit/attachments/20070901/a479b3a5/attachment-0003.htm>