On 15/03/2024 13:31, Takashi Yano via Cygwin-apps wrote:
On Fri, 15 Mar 2024 13:14:49 +0000
Jon Turney wrote:
On 15/03/2024 09:15, Takashi Yano via Cygwin-apps wrote:
I uploaded svt-av1 1.8.0-2 few hours ago, however
it does not appear on the mirror servers so far.
Was anything wrong?
Sorry, things will be a little slower than usual (uploads may take up to
4 hours to get processed) until I get around to fixing up things for
some changes made on sourceware to provide better isolation.
I see that this upload was declined because svt-av1 2.0.0 already exists.
I guess you really want to upload it, as it provides a different set of
shared libraries to 2.0.0. Please let me know.
1.8.0-2 is necessary for changing packaging.
I see. I configured the necessary exception, sot his should be all
uploaded now.
1.8.0-1: cygSvtAv1Enc-1.dll and cygSvtAv1Dec-0.dll are in libsvtav1,
However,
2.0.0-1: cygSvtAv1Enc-2.dll and cygSvtAv1Dec-0.dll are built.
So, I made
1.8.0-2: cygSvtAv1Enc-1.dll is in libsvtav1enc1 and cygSvtAv1Dec-0 is in
libsvtav1dec0
both obsolete libsvtav1
for migration.
Hmm... maybe your thinking here is not quite clear.
You cannot assume that an installation is upgraded often enough that it
receives every version of every package.
(And in this case, where 1.8.0-2 appears in the repository after 2.0.0
does, it's not going to get automatically installed anywhere)
So, as a principle, every version of a package must contain complete
instructions for upgrading to it.
In this particular case, that means the cygport should contain
libsvtav1dec0_OBSOLETES=libsvtav1
for as long as the package produces libsvtav1dec0.
(In fact, I think this all happens to work as desired because libsvtav1
is also obsoleted by the non-longer produced libsvtav1enc1, but I just
point this out for completeness)
The first step I did was wrong, i.e. I should not have package which
includes dlls whose versions are different. Sorry.
No problem. Mistakes happen.
