Le 08/25/2010 09:08 PM, M.-A. Lemburg a écrit : > I guess that's where part of the misunderstanding originates: > the type of conflict can be many things and may well only > show up in certain applications using the packages, but > not necessarily all of them. > > At the very least, there should be an extra field "Conflict-Description" > which describes the type of conflict to the user and then lets him or > her decide whether the conflict is a problem or not for the intended > use. This sounds like a good idea to have something to output to the user, in order to let him resolve the conflict the right way.
> I have a feeling that the introduction of this field originated > from some application space problem that you're trying to fix > at the package level. Tarek, any hints about the origin of this field ? (conflict) > Also note that a the use cases you and others have mentioned can > easily be solved using meta-packages and dependencies on these or > by the installer checking whether there are module name or > file conflicts (i.e. two packages wanting to install the same > module or create the same file). True. Maybe need we to make a complex packaging example, with good practices to follow, and an companion document for this purpose, as good packaging solutions seems to be non-obvious for end users. _______________________________________________ Catalog-SIG mailing list [email protected] http://mail.python.org/mailman/listinfo/catalog-sig
