<div class="gmail_quote">On Tue, Nov 20, 2012 at 4:07 PM, Glenn Linderman <span dir="ltr"><<a href="mailto:v+python@g.nevcal.com" target="_blank">v+python@g.nevcal.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

  
    
  
  <div bgcolor="#FFFFFF" text="#330033"><div class="im">
    <div>On 11/20/2012 12:46 PM, PJ Eby wrote:<br>
    </div>
    <blockquote type="cite"><div class="gmail_quote">
      <div>
          I personally don't think that forks claiming to "provide"
          something is really a good thing to encourage; ISTM that
          saying a package *conflicts* with another is more accurate,
          e.g. distribute Conflicts-Dist setuptools.  I also think
          distributions should say they are obsoleted, rather than
          allowing other distributions to obsolete them.<br>
        </div>
      </div>
    </blockquote>
    </div>
    Obsolete distributions won't say they are obsoleted, unless they
    receive further maintenance. However, if the distribution is
    obsolete because the maintainer has lost interest, they won't
    receive further maintenance.</div></blockquote><div><br>(We've been over this before, the last time this discussion came up on the Distutils-SIG for a previous Metadata PEP a year or two back, but here goes....)<br>
<br>Obsoleting a package is for handling renames and support transitions.  For example, if it actually did anything to do so, I'd mark RuleDispatch as obsoleted-by PEAK, the Pylons folks might mark some version of that as obsoleted-by Pyramid, etc.  To put it another way, marking a package obsolete is part of deprecation and replacement, not an unsubstantiated third-party claim about the maintenance status of an unrelated project.<br>
<br>If a package is *actually* dead, there's no real point to declaring that something else obsoletes it, and certainly no reason to put it in metadata form.  Otherwise, we could have Twisted claiming to obsolete GEvent and vice-versa at the same time.  Which one should an installer believe?  It makes no sense in a standard where the project's maintainers can say whatever they want about somebody else's project.  The scope of authority for automatically-consumed metadata should *only* encompass the project that provided the metadata.<br>
<br></div></div>