[Python-Dev] Keyword meanings [was: Accept just PEP-0426]
a.badger at gmail.com
Thu Dec 6 07:49:25 CET 2012
On Wed, Dec 05, 2012 at 07:34:41PM -0500, PJ Eby wrote:
> On Wed, Dec 5, 2012 at 6:07 PM, Donald Stufft <donald.stufft at gmail.com> wrote:
> Nobody has actually proposed a better one, outside of package renaming
> -- and that example featured an author who could just as easily have
> used an obsoleted-by field.
How about pexpect and pextpect-u as a better example?
> > Very convenient to declare that one of the major use cases for
> > Obsoletes over Obsoleted-By is not valid because of your own
> > personal opinions.
> I didn't say it was invalid, I said:
> """Note that "the author of package X no longer maintains it" does not
> equal "package Y is entitled to name itself the successor and enforce
> this upon all users"""
> These things are not equal. AFAIK, well-managed Linux distros do not
> allow random forkers to declare themselves the official successor to a
> defunct package, so any analogy between this use case in the Python
> world and the distro world is strained at *best*.
Note that although well-managed Linux distros attempt to control random
forking internally, the distro package managers don't prevent people from
installing from third parties. So Ubuntu PPAs, upstreams that provide their
own rpms/debs, and major third party repos (for instance, rpmfusion as
an add-on repo to Fedora) all have and sometimes (mis)use the ability to
Obsolete packages in the base repository.
So Donald isn't stretching the relationship quite as far as you make it out.
The ecosystem of packages for a distro carries uncontrolled packages just as
much as pypi.
> > and merely having the ability to use it when it is the best tool for the job
> > isn't going to cause any great issue.
> One of the posts I linked presents an instance where it would have
> actually *harmed* things to specify it, and it's quite easy to see how
> the same problem would arise if used for non-file-related conflicts...
> And the problem present is *directly* tied to the lack of a
> third-party Z who decides whether X and Y, as configured for release Q
> of distro P, "conflict".
> This is not a problem that is solvable even in *principle* for an
> automated tool in the absence of party Z, which means that any such
> field's actual function is limited to a heads-up to a human user.
And the same for Provides. (ie: latest foo is 0.6c; bar Provides: foo-0.6d.
an automated tool that finds both foo and bar in its dep tree can choose to
install bar and not foo.)
The ability for this class of fields to cause harm is not, to me,
a compelling argument not to include them. It could be an argument to
explicitly tell implementers of install tools that they all have caveats
when used with pypi and similar unpoliced community package repositories.
The install tools can then choose how they wish to deal with those caveats.
Some example strategies: choose to prompt the user as to which to install,
choose to always treat the fields as human-informational only, mark some
repositories as being trusted to contain packages where these fields are
active and other repositories where the fields are ignored.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 198 bytes
Desc: not available
More information about the Python-Dev