Re: Quarterly 13.3 amd64 package inconsistency?
- In reply to: Chris Ross : "Re: Quarterly 13.3 amd64 package inconsistency?"
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
Date: Sat, 24 Aug 2024 21:45:08 UTC
On 24/08/2024 19:48, Chris Ross wrote: [..] >>> I haven't tested that software nor confirmed version dependencies. The ports tree shows the versions in the trees as mentioned but does not have a version requirement checked for dependencies. >> >> Dependency info referenced above. Is there perhaps an issue with the >> py-openssl port then? > > Coming back to this. I temporarily switched my pkg config to use latest > instead of quarterly, which allowed me to pull in pyopenssl 24.1.0.1 > and I am now running. However, I think the problem still exists in > quarterly, and should be corrected. > > I’ll drop it if no-one else cares, but it seems a “broken window” that > should be fixed. We use quarterly packages on all our machines and more and more often I see that something is broken in quarterly and the fix never makes it from HEAD to quarterly, or that a package in quarterly has a security vulnerability, the fix is in HEAD but no one merges the security fix into quarterly (e.g. Postgres). So increasingly I feel like quarterly serves no purpose except to freeze for three months, even if it's broken. I think if anything is broken in quarterly and the fix is known (in HEAD) it should be MFH. I know it is sometimes complicated because of cross dependencies, but other cases are simple. Are some rules for MFH to quarterly defined in handbook or somewhere else? Kind regards Miroslav Lachman