<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html> <head> <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type"> </head> <body bgcolor="#ffffff" text="#000000"> Richard Hughes wrote: <blockquote cite="mid:15e53e180708311823i57affbcdx8ddbc89c438144df@mail.gmail.com" type="cite"> <pre wrap="">On 01/09/2007, Tom Parker <a class="moz-txt-link-rfc2396E" href="mailto:palfrey@tevp.net"><palfrey@tevp.net></a> wrote: </pre> <blockquote type="cite"> <pre wrap="">Richard Hughes wrote: </pre> <blockquote type="cite"> <blockquote type="cite"> <pre wrap="">* "Conflicts" - "Won't work with that package" </pre> </blockquote> <pre wrap="">Hmm, I'm not sure conflicts are a good idea in /any/ packaging system. </pre> </blockquote> <pre wrap="">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. </pre> </blockquote> <pre wrap=""> Sure. </pre> <blockquote type="cite"> <pre wrap="">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 <a class="moz-txt-link-freetext" href="http://www.debian.org/doc/debian-policy/ch-relationships.html">http://www.debian.org/doc/debian-policy/ch-relationships.html</a>) </pre> </blockquote> <pre wrap=""> 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" </pre> <blockquote type="cite"> <blockquote type="cite"> <blockquote type="cite"> <pre wrap="">* "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" </pre> </blockquote> <pre wrap="">Umph, thats sortof cracktastic in my book. </pre> </blockquote> <pre wrap="">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. </pre> </blockquote> <pre wrap=""> 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. </pre> <blockquote type="cite"> <blockquote type="cite"> <blockquote type="cite"> <pre wrap="">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. </pre> </blockquote> <pre wrap="">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. </pre> </blockquote> <pre wrap="">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? </pre> </blockquote> <pre wrap=""> 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. </pre> <blockquote type="cite"> <pre wrap="">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. </pre> </blockquote> <pre wrap=""> 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 <a class="moz-txt-link-abbreviated" href="mailto:PackageKit@lists.freedesktop.org">PackageKit@lists.freedesktop.org</a> <a class="moz-txt-link-freetext" href="http://lists.freedesktop.org/mailman/listinfo/packagekit">http://lists.freedesktop.org/mailman/listinfo/packagekit</a> </pre> </blockquote> +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 </body> </html>