[138221] trunk/dports/multimedia/mpv

[Ryan Schmidt]

On Jul 5, 2015, at 9:30 AM, Mihai Moldovan wrote:

> On 05.07.2015 10:32 AM, Ryan Schmidt wrote:
>>> On Jul 2, 2015, at 11:14 AM, ionic at macports.org wrote:
>>> +# Remove after 06-28-2016.
>>> +variant mp3 description {Legacy compatibility variant for MP3 support via mpg123. Will be removed soon.} {
>>> +    notes-append "
>>> +                   You have enabled the legacy mp3 variant.
>>> +                   Upstream ceased using mpg123 in version 0.8.0 and removed support
>>> +                   completely in 0.9.0.
>>> +                   Decoding and playback of MP3 content is still available via
>>> +                   ffmpeg, so no action is needed on your side.
>>> +                 "
>>> }
>> 
>> If no action is needed on the user's part to continue to get mp3 support, then there is no reason not to remove the variant immediately. Keeping the variant only serves to confuse the user by printing a pointless message, and causes the user to have a non-default set of variants, meaning if there were binaries of this port, the user wouldn't be able to get them until they manually deselected this variant.
> 
> Hum, okay.
> 
> I only know the policy of keeping any variant to be removed around as a legacy
> variant that does nothing for a year to provide a better upgrade path.
> 
> Also, if I just removed the mp3 variant, I feared users might panic and think
> that MP3 playback is unsupported now (which is obviously not the case.)
> 
> Are you sure that's not breaking the previously mentioned policy?

The legacy compatibility variants we keep around for a year never do nothing. They always do something: specifically, they ensure that a user who had installed a port with a particular selected variant will, after an upgrade, still have the same functionality, if it is still available.

For example, if a variant has changed names, and the new variant is not a default variant, then keep the old variant around, marked as requiring the new variant:

variant oldvariant requires newvariant description {Legacy compatibility variant} {}


But if the commands in the old variant are no longer available and there is either no longer a way to get that functionality or that functionality is now enabled by default, then keeping the old variant serves no purpose so it should be removed.


I don't think users will panic if a variant disappears. It's quite normal for a maintainer to either fold formerly variant behavior into the default condition of the port (because having fewer choices is better), or else to break formerly default behavior out into a variant (perhaps because a library it depends on would affect the distributability of the port).