The ports collection has some serious issues

John Marino at
Fri Dec 16 16:16:33 UTC 2016

On 12/16/2016 10:09, Roger Marquis wrote:
>> I never understood why people went ape-**** over it, unless they don't
>> understand what "deprecated without expiration" actually means.
> Perhaps then this is the crux of the issue.  From my experience
> "deprecated" means only that something will not appear in a future
> version of the OS.  It implies nothing about the suitability of the
> software itself.  "deprecated without expiration" is a contradiction.

 From porters handbook, section 12.15:
"It is possible to set DEPRECATED without an EXPIRATION_DATE (for 
instance, recommending a newer version of the port), but the converse 
does not make any sense."

So it's not a contradiction.  Ports that have a specific removal date 
must have EXPIRATION_DATE set.  If you say, well DEPRECATION implies 
removal, I'd agree, but it's at an indefinite time and I'd say that time 
would come when portmaster no longer works on the current ports tree. 
When that happens (and it probably will happen) then EXPIRATION can be set.

>> If Torsten drops maintainership then some sort of "strong" warning
>> should come with that drop.  I would be satisfied with adding a
>> descriptive DEPRECATED message myself.
> TZ or no TZ we should drop the deprecation notice until it has an
> expiration date and clarify the warning terms (ASAP).  At least that
> way, when a thread like this comes up in the future, the only response
> needed would be a pointer to the install message.

Which notice should we drop?  There's no DEPRECATION set now.  There's 
no warning set.  portmaster is not marked as "deprecated".

And as the handbook points out: You can't have EXPIRATION without 
DEPRECATED, but it's perfectly legal to have the reverse.  It's 
documented clearly.


This email has been checked for viruses by Avast antivirus software.

More information about the freebsd-ports mailing list