2nd deprecation campaign

[Baptiste Daroussin]

2011/6/17 b. f. <bf1783 at googlemail.com>:
> On 6/17/11, Baptiste Daroussin <bapt at freebsd.org> wrote:
>> 2011/6/16 b. f. <bf1783 at googlemail.com>:
>>> bapt wrote:
>>>>I am in the middle of a new deprecation campaign, to remove ports
>>>>where no more distfiles are publicly available (no other OS mirrors
>>>>doesn't count except if they are the upstream of course).
>>>>
>>>>Maybe some will be false positive (I will try to not have too much of
>>>> them).
>>>
>>> Could you please explain how you are checking this?  Just looking at
>>> some of the recent deprecations, graphics/peps, graphics/vcg, and
>>> graphics/xfig are still available.  On earlier ones,
>>> graphics/libconvolve exists in the jack_convolve section of the heaven
>>> sourceforge project:
>>>
>>
>> Those are not deprecated but broken, broken because they don't fetch
>> and they need someone to take care of it, to send the new master_site
>> line for example, I don't have time enough to update/fix all the
>> master_site lines from the whole ports tree, so I I see none of the
>> said master_site provide the distfiles, it is marked as broken because
>> that is what it is.
>>
>
> Well, the build often isn't broken (and users don't notice that it is
> "broken") because the distfile may be cached locally, or on the
> project servers, so this is more a matter of policy in many cases.
> But I take your point.  I saw that you began doing this soon after you
> announced a deprecation campaign, so I wasn't sure if your were doing
> this a preliminary step, before deprecating them in the near future.
>
> ...
>
>>> http://packages.qa.debian.org/g/gsmlib.html
>>
>> Debian having the package doesn't mean that they are the upstream.
>>>
>
> No, but in this case the Debian maintainer has taken over that role in
> the absence of the original authors, as described in the changelog
> there.
>
> b.
>

Thanks for pointing this, but it still need a patch, because the
distfile has change.

Thanks.
Bapt