On Mon, Aug 23, 2010 at 10:02 AM, P.J. Eby <[email protected]> wrote: > At 03:37 PM 8/23/2010 +0200, Tarek Ziadé wrote: >> >> This will never happen: the installer will stop and just state that >> there's a conflict >> and the installation cannot continue. > > What I was trying to point out is that if this is the intended/suggested use > of the field, then the PEP should say so. > > That way, when somebody writing software is looking at the PEP, they will > see explicit guidance that it's not intended to cause the removal of (or > prevent the installation/re-installation of) the "obsoleted" package.
Sure, we can say something like: Installers should never try to resolve a conflict occurring during an installation, that would remove or upgrade a project that is already installed. The best way to handle this problem is to mention it to the end-user in their interface, so he can manually decide what to do. > > However, I'm still not clear on why "obsoletes" should be treated as a > conflict; if it's conflicting, then why not just *also* say it's conflicting > via the Conflicts fieled? Well, this is also the case when a project depends on Foo > 1.0 and Foo 0.9 is installed. We do have several scenarii of conflicts, and Obsoletes just differs from Conflicts in the nature of the conflict, and how the installer will inform the user. IOW, Obsoletes could probably be ignored by the installer and just raise a warning, whereas conflicts needs to stop the process. > In other words, Obsoletes seems like something purely informational, rather > than something a tool should consume. Well the only nuance is that --depending on the trust you have in the project of course-- You know that you will get Bar, if you install Foo which Obsoletes it, and that you don't need to install Bar anymore. e.g. It just become redundant. > > That being said, I really just want the intent (whatever that may be) to be > stated clearly in the PEP, rather than being left as an assumption for the > reader to guess. Sure, fair enough -- Tarek Ziadé | http://ziade.org _______________________________________________ Catalog-SIG mailing list [email protected] http://mail.python.org/mailman/listinfo/catalog-sig
