"Ian D. Leroux" <idleroux%fastmail.fm@localhost> writes: > Since we're suggesting packages to prune, I note that pkgsrc now offers > three seperate versions of the vlc media player, > > multimedia/vlc > multimedia/vlc2 > multimedia/vlc21 > > I have a bug (pkg/49447) open against the first of these, which I > stopped chasing when I realised that more recent versions were > available and worked for me. So is anyone still using vlc-1.x or > vlc-2.0.x? Do they support environments which current vlc does not? If > not, then I suggest we drop the older packages (and close the > associated PRs). If the older versions are still useful to someone, > I'll try to find time this spring to chase down that bug, but would > appreciate some help Certainly it's fair to put a note in the PRs asking the submitters to etiher retest with vlc21 or to explain why that isn't a reasonable approach. My usual request: proposing deletion should explain when the to-be-deleted packages were EOLed, or superceded, and why it's fair to say to anyone still using them that they are delinquent for not updating (that's a bit harsh, but captures the point). So it would help if you could write a deletion proposal that allows people who don't understand vlc to judge the merits. I have no idea when the last vlc1 release was, and when the first vlc2 release was for which "this is stable - everybody should upgrade". (I'm not objecting to the removal at all; I have no idea of the merits of the issue.) > At a minimum, would it be worth renaming packages so that > multimedia/vlc points to the most recent version on offer rather than > the most ancient one? Renaming generally feels like unnecessary churn to me. I've come to believe (somehat fuzzily - this is not meant to be doctrine) that packages (upstreams really) fall into two categories: ones for which there is enough attention to backwards compatibility and lack of bloat and therefore it's reasonable to just have one version in pkgsrc, and ones which have enough issues that there tends to be a need/desire for multiple versions. Of course one can place upstreams into this category at any point in time. Beyond that, I think upstreams tend to be in one or the other category semi-permanently, even if at any one time we only have one version. So my preference is that stable upstream packages should have unadorned names, and packages that tend to need multiple versions should *only* have packages with a version suffix. Note that this is just my individual opinion, not policy and not 100% existing practice. So if multimedia/vlc were removed, that would fix the "why isn't vlc current" issue, and pave the way for vlc22 or whatever eventually.
Description: PGP signature