"David H. Gutteridge" <david%gutteridge.ca@localhost> writes: > wm/marco should work fine with Zenity 3.x, it's integrated that way > elsewhere. If that's the only remaining concern, I think the newer > Zenity version should just replace what we have now. If someone really > wants the older x11/gdm and needs the older Zenity, I'd prefer that the > older one is renamed zenity2 (along with renaming the older gdm, to > denote that is crufty software). I haven't tested the newer Zenity in > wip with Marco, but I could try it. I'm of course fine with people who know zenity deciding to just update it and not have zenity2, but as far as naming goes, churn is bad, both in terms of directory renaming, in terms of package tools needing to flip between versions, and the messy dependency chains. We have settled on the following norm: packages follow one of two plans There is only one version of a package in pkgsrc. This has been true for a while and is expected to be true indefinitely. Of course the package gets updated. There is some reason why having only the upstream-recommended version is problematic. Every version of the package in pkgsrc has a version suffix. Once on this plan, the package remains with a version suffix even during times there is only one version. If upstream permanently resolves the compat issues that led to needing too, and this remains true for years, then it can flip back to single, unversioned. and we have a bias to "just one" absent a compelling reason. That said, because churn is bad, often when we have a single name, and move to versioned, it's done as foo-2 exists foo3 is added foo4 is added foo is removed so it's a less-churny transition leaving the plain name for a while. Also, we don't insist that foo3 install /usr/pkg/bin/foo3. Often it installs plain foo and you can only have one. Unless that's terrible for users, it's preferred. So I would say absent some really good reason why updating to 3 is bad, just update. It's always possible to just put the old version in wip/zenity2 and tell people who need it to use it from wip, and that's reasonable if using it is odd rather than substantial. Overall I think it's best to focus on bringing all other packages forward to the point where they can use the recommended release.
Attachment:
signature.asc
Description: PGP signature