Where have svt-av1 1.8.0-2 gone?

Where have svt-av1 1.8.0-2 gone?

[Takashi Yano]

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?

-- 
Takashi Yano <takashi.yano@nifty.ne.jp>

Re: Where have svt-av1 1.8.0-2 gone?

[Jon Turney]

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.

Re: Where have svt-av1 1.8.0-2 gone?

[Takashi Yano]

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.

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.

The first step I did was wrong, i.e. I should not have package which
includes dlls whose versions are diffrent. Sorry.

-- 
Takashi Yano <takashi.yano@nifty.ne.jp>

Re: Where have svt-av1 1.8.0-2 gone?

[Jon Turney]

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.

Re: Where have svt-av1 1.8.0-2 gone?

[Takashi Yano]

On Fri, 15 Mar 2024 16:58:06 +0000
Jon Turney wrote:
> 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)

What I did was:
1.8.0-1:
libsvtav1_CONTENTS="usr/bin/*.dll"

1.8.0-2:
libsvtav1enc1_CONTENTS="usr/bin/cygSvtAv1Enc-1.dll"
libsvtav1enc1_OBSOLETES=libsvtav1
libsvtav1dec0_CONTENTS="usr/bin/cygSvtAv1Dec-0.dll"
libsvtav1dec0_OBSOLETES=libsvtav1

2.0.0-1:
libsvtav1enc2_CONTENTS="usr/bin/cygSvtAv1Enc-2.dll"
libsvtav1dec0_CONTENTS="usr/bin/cygSvtAv1Dec-0.dll"

This expected:
1.8.0-1 -> 1.8.0-2 -> 2.0.0-1
libsvtav1(1.8.0-1) -> libsvtav1enc1(1.8.0-2) + libsvtav1dec0(1.8.0-2)
	-> libsvt1enc1(1.8.0-2) + libsvtav1dec0(2.0.0-2)

However, this does not seem to work as I expected.
My expectation was that both libsvtav1enc1(1.8.0-2) and libsvtav1dec0(1.8.0-2)
are installed for upgrading libsvtav1(1.8.0-1).

Instead, I found

1.8.0-2:
libsvtav1_CATEGORY="_obsolete"
libsvtav1_REQUIRES="libsvtav1enc1 libsvtav1dec0"
libsvtav1enc1_CONTENTS="usr/bin/cygSvtAv1Enc-1.dll"
libsvtav1dec0_CONTENTS="usr/bin/cygSvtAv1Dec-0.dll"

works as expected.
Is it possible to change it like this now?

-- 
Takashi Yano <takashi.yano@nifty.ne.jp>

Re: Where have svt-av1 1.8.0-2 gone?

[Takashi Yano]

On Sat, 16 Mar 2024 09:39:33 +0900
Takashi Yano wrote:
> On Fri, 15 Mar 2024 16:58:06 +0000
> Jon Turney wrote:
> > 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)
> 
> What I did was:
> 1.8.0-1:
> libsvtav1_CONTENTS="usr/bin/*.dll"
> 
> 1.8.0-2:
> libsvtav1enc1_CONTENTS="usr/bin/cygSvtAv1Enc-1.dll"
> libsvtav1enc1_OBSOLETES=libsvtav1
> libsvtav1dec0_CONTENTS="usr/bin/cygSvtAv1Dec-0.dll"
> libsvtav1dec0_OBSOLETES=libsvtav1
> 
> 2.0.0-1:
> libsvtav1enc2_CONTENTS="usr/bin/cygSvtAv1Enc-2.dll"
> libsvtav1dec0_CONTENTS="usr/bin/cygSvtAv1Dec-0.dll"
> 
> This expected:
> 1.8.0-1 -> 1.8.0-2 -> 2.0.0-1
> libsvtav1(1.8.0-1) -> libsvtav1enc1(1.8.0-2) + libsvtav1dec0(1.8.0-2)
> 	-> libsvt1enc1(1.8.0-2) + libsvtav1dec0(2.0.0-2)
> 
> However, this does not seem to work as I expected.
> My expectation was that both libsvtav1enc1(1.8.0-2) and libsvtav1dec0(1.8.0-2)
> are installed for upgrading libsvtav1(1.8.0-1).
> 
> Instead, I found
> 
> 1.8.0-2:
> libsvtav1_CATEGORY="_obsolete"
> libsvtav1_REQUIRES="libsvtav1enc1 libsvtav1dec0"
> libsvtav1enc1_CONTENTS="usr/bin/cygSvtAv1Enc-1.dll"
> libsvtav1dec0_CONTENTS="usr/bin/cygSvtAv1Dec-0.dll"
> 
> works as expected.
> Is it possible to change it like this now?

If possible, I can upload fixed 1.8.0-2 (or 1.8.0-3).

-- 
Takashi Yano <takashi.yano@nifty.ne.jp>

Re: Where have svt-av1 1.8.0-2 gone?

[Jon Turney]

On 16/03/2024 00:48, Takashi Yano via Cygwin-apps wrote:
> On Sat, 16 Mar 2024 09:39:33 +0900
> Takashi Yano wrote:
[...]
>>
>> This expected:
>> 1.8.0-1 -> 1.8.0-2 -> 2.0.0-1
>> libsvtav1(1.8.0-1) -> libsvtav1enc1(1.8.0-2) + libsvtav1dec0(1.8.0-2)
>> 	-> libsvt1enc1(1.8.0-2) + libsvtav1dec0(2.0.0-2)
>>
>> However, this does not seem to work as I expected.

What unexpected thing happens?

I guess you only get one of libsvtav1enc1 or libsvtav1dec0 (since if 
these both are marked "obsoletes: libsvtav1", to the dependency solver 
that mean that either of can replace libsvtav1, and provides everything 
that it provides.

So maybe the best solution is:

libsvtav1dec0_OBSOLETES=libsvtav1
libsvtav1dec0_REQUIRES=libsvtav1enc1

So libsvtav1 is replaced by both libsvtav1dec0 and libsvtav1enc1

>> My expectation was that both libsvtav1enc1(1.8.0-2) and libsvtav1dec0(1.8.0-2)
>> are installed for upgrading libsvtav1(1.8.0-1).
>>
>> Instead, I found
>>
>> 1.8.0-2:
>> libsvtav1_CATEGORY="_obsolete"
>> libsvtav1_REQUIRES="libsvtav1enc1 libsvtav1dec0"
>> libsvtav1enc1_CONTENTS="usr/bin/cygSvtAv1Enc-1.dll"
>> libsvtav1dec0_CONTENTS="usr/bin/cygSvtAv1Dec-0.dll"

Yeah, this should work, but is not longer preferred because you end up 
with an empty libsvtav1 hanging around forever...

>> works as expected.
>> Is it possible to change it like this now?

I've tweaked the existing dependencies based on my reasoning above. 
Please let me know if this still isn't working right.

Re: Where have svt-av1 1.8.0-2 gone?

[Takashi Yano]

On Sat, 16 Mar 2024 17:49:30 +0000
Jon Turney wrote:
> On 16/03/2024 00:48, Takashi Yano via Cygwin-apps wrote:
> > On Sat, 16 Mar 2024 09:39:33 +0900
> > Takashi Yano wrote:
> [...]
> >>
> >> This expected:
> >> 1.8.0-1 -> 1.8.0-2 -> 2.0.0-1
> >> libsvtav1(1.8.0-1) -> libsvtav1enc1(1.8.0-2) + libsvtav1dec0(1.8.0-2)
> >> 	-> libsvt1enc1(1.8.0-2) + libsvtav1dec0(2.0.0-2)
> >>
> >> However, this does not seem to work as I expected.
> 
> What unexpected thing happens?
> 
> I guess you only get one of libsvtav1enc1 or libsvtav1dec0 (since if 
> these both are marked "obsoletes: libsvtav1", to the dependency solver 
> that mean that either of can replace libsvtav1, and provides everything 
> that it provides.
> 
> So maybe the best solution is:
> 
> libsvtav1dec0_OBSOLETES=libsvtav1
> libsvtav1dec0_REQUIRES=libsvtav1enc1
> 
> So libsvtav1 is replaced by both libsvtav1dec0 and libsvtav1enc1

Looks great!

> >> My expectation was that both libsvtav1enc1(1.8.0-2) and libsvtav1dec0(1.8.0-2)
> >> are installed for upgrading libsvtav1(1.8.0-1).
> >>
> >> Instead, I found
> >>
> >> 1.8.0-2:
> >> libsvtav1_CATEGORY="_obsolete"
> >> libsvtav1_REQUIRES="libsvtav1enc1 libsvtav1dec0"
> >> libsvtav1enc1_CONTENTS="usr/bin/cygSvtAv1Enc-1.dll"
> >> libsvtav1dec0_CONTENTS="usr/bin/cygSvtAv1Dec-0.dll"
> 
> Yeah, this should work, but is not longer preferred because you end up 
> with an empty libsvtav1 hanging around forever...
> 
> >> works as expected.
> >> Is it possible to change it like this now?
> 
> I've tweaked the existing dependencies based on my reasoning above. 
> Please let me know if this still isn't working right.

Thanks you very much!

Could you please also remove:
libsvtav1enc1_OBSOLETES=libsvtav1
because it seems that this conflicts with
libsvtav1dec0_OBSOLETES=libsvtav1
?

-- 
Takashi Yano <takashi.yano@nifty.ne.jp>

Re: Where have svt-av1 1.8.0-2 gone?

[Takashi Yano]

On Sun, 17 Mar 2024 10:06:31 +0900
Takashi Yano wrote:
> On Sat, 16 Mar 2024 17:49:30 +0000
> Jon Turney wrote:
> > On 16/03/2024 00:48, Takashi Yano via Cygwin-apps wrote:
> > > On Sat, 16 Mar 2024 09:39:33 +0900
> > > Takashi Yano wrote:
> > [...]
> > >>
> > >> This expected:
> > >> 1.8.0-1 -> 1.8.0-2 -> 2.0.0-1
> > >> libsvtav1(1.8.0-1) -> libsvtav1enc1(1.8.0-2) + libsvtav1dec0(1.8.0-2)
> > >> 	-> libsvt1enc1(1.8.0-2) + libsvtav1dec0(2.0.0-2)
> > >>
> > >> However, this does not seem to work as I expected.
> > 
> > What unexpected thing happens?
> > 
> > I guess you only get one of libsvtav1enc1 or libsvtav1dec0 (since if 
> > these both are marked "obsoletes: libsvtav1", to the dependency solver 
> > that mean that either of can replace libsvtav1, and provides everything 
> > that it provides.
> > 
> > So maybe the best solution is:
> > 
> > libsvtav1dec0_OBSOLETES=libsvtav1
> > libsvtav1dec0_REQUIRES=libsvtav1enc1
> > 
> > So libsvtav1 is replaced by both libsvtav1dec0 and libsvtav1enc1
> 
> Looks great!
> 
> > >> My expectation was that both libsvtav1enc1(1.8.0-2) and libsvtav1dec0(1.8.0-2)
> > >> are installed for upgrading libsvtav1(1.8.0-1).
> > >>
> > >> Instead, I found
> > >>
> > >> 1.8.0-2:
> > >> libsvtav1_CATEGORY="_obsolete"
> > >> libsvtav1_REQUIRES="libsvtav1enc1 libsvtav1dec0"
> > >> libsvtav1enc1_CONTENTS="usr/bin/cygSvtAv1Enc-1.dll"
> > >> libsvtav1dec0_CONTENTS="usr/bin/cygSvtAv1Dec-0.dll"
> > 
> > Yeah, this should work, but is not longer preferred because you end up 
> > with an empty libsvtav1 hanging around forever...
> > 
> > >> works as expected.
> > >> Is it possible to change it like this now?
> > 
> > I've tweaked the existing dependencies based on my reasoning above. 
> > Please let me know if this still isn't working right.
> 
> Thanks you very much!
> 
> Could you please also remove:
> libsvtav1enc1_OBSOLETES=libsvtav1
> because it seems that this conflicts with
> libsvtav1dec0_OBSOLETES=libsvtav1
> ?

I noticed that the following happen even with obove if
the package which requires libsvtav1 is installed.
At the first upgrade,
Uninstall libsvt1v1 1.8.0-1
Install libsvtav1dec0 1.8.0-2
Install libsvtav1enc1 1.8.0-2
that is as expected except for libsvtav1dec0 is not latest.

However, at the next upgrade (just run setup again),
Uninstall libsvtav1dec0 1.8.0-2
Install libsvtav1 1.8.0-1
Install libsvtav1dec0 2.0.0-1
happens. This causes conflict:
$ cygcheck -f /usr/bin/cygSvtAv1Dec-0.dll
libsvtav1-1.8.0-1
libsvtav1dec0-2.0.0-1

Im not sure why this happens.

Contrary to your idea,
libsvtav1enc1_OBSOLETES="libsvtav1"
libsvtav1enc1_REQUIRES="libsvtav1dec0"
the followings happen as expected.
Uninstall libsvtav1 1.8.0-1
Install libsvtav1dec0 2.0.0-1
Install libsvtav1enc1 1.8.0-2

Of cource,
libsvtav1dec0_OBSOLETES=libsvtav1
should be removed in this case.

What do you think?

-- 
Takashi Yano <takashi.yano@nifty.ne.jp>

Re: Where have svt-av1 1.8.0-2 gone?

[Jon Turney]

On 17/03/2024 01:43, Takashi Yano via Cygwin-apps wrote:
> On Sun, 17 Mar 2024 10:06:31 +0900
> Takashi Yano wrote:
>> On Sat, 16 Mar 2024 17:49:30 +0000
>> Jon Turney wrote:
>>> On 16/03/2024 00:48, Takashi Yano via Cygwin-apps wrote:
>>>> On Sat, 16 Mar 2024 09:39:33 +0900
>>>> Takashi Yano wrote:
>>> [...]
>>>>>
>>>>> This expected:
>>>>> 1.8.0-1 -> 1.8.0-2 -> 2.0.0-1
>>>>> libsvtav1(1.8.0-1) -> libsvtav1enc1(1.8.0-2) + libsvtav1dec0(1.8.0-2)
>>>>> 	-> libsvt1enc1(1.8.0-2) + libsvtav1dec0(2.0.0-2)
>>>>>
>>>>> However, this does not seem to work as I expected.
>>>
>>> What unexpected thing happens?
>>>
>>> I guess you only get one of libsvtav1enc1 or libsvtav1dec0 (since if
>>> these both are marked "obsoletes: libsvtav1", to the dependency solver
>>> that mean that either of can replace libsvtav1, and provides everything
>>> that it provides.
>>>
>>> So maybe the best solution is:
>>>
>>> libsvtav1dec0_OBSOLETES=libsvtav1
>>> libsvtav1dec0_REQUIRES=libsvtav1enc1
>>>
>>> So libsvtav1 is replaced by both libsvtav1dec0 and libsvtav1enc1
>>
>> Looks great!
>>
>>>>> My expectation was that both libsvtav1enc1(1.8.0-2) and libsvtav1dec0(1.8.0-2)
>>>>> are installed for upgrading libsvtav1(1.8.0-1).
>>>>>
>>>>> Instead, I found
>>>>>
>>>>> 1.8.0-2:
>>>>> libsvtav1_CATEGORY="_obsolete"
>>>>> libsvtav1_REQUIRES="libsvtav1enc1 libsvtav1dec0"
>>>>> libsvtav1enc1_CONTENTS="usr/bin/cygSvtAv1Enc-1.dll"
>>>>> libsvtav1dec0_CONTENTS="usr/bin/cygSvtAv1Dec-0.dll"
>>>
>>> Yeah, this should work, but is not longer preferred because you end up
>>> with an empty libsvtav1 hanging around forever...
>>>
>>>>> works as expected.
>>>>> Is it possible to change it like this now?
>>>
>>> I've tweaked the existing dependencies based on my reasoning above.
>>> Please let me know if this still isn't working right.
>>
>> Thanks you very much!
>>
>> Could you please also remove:
>> libsvtav1enc1_OBSOLETES=libsvtav1
>> because it seems that this conflicts with
>> libsvtav1dec0_OBSOLETES=libsvtav1
>> ?

Oops. I obviously needed to do that, but forget. Then I did it, and 
forget to tell you that I'd done it.

Hopefully, that resolves the misbehavior you describe below.

> 
> I noticed that the following happen even with obove if
> the package which requires libsvtav1 is installed.
> At the first upgrade,
> Uninstall libsvt1v1 1.8.0-1
> Install libsvtav1dec0 1.8.0-2
> Install libsvtav1enc1 1.8.0-2
> that is as expected except for libsvtav1dec0 is not latest.
> 
> However, at the next upgrade (just run setup again),
> Uninstall libsvtav1dec0 1.8.0-2
> Install libsvtav1 1.8.0-1
> Install libsvtav1dec0 2.0.0-1
> happens. This causes conflict:
> $ cygcheck -f /usr/bin/cygSvtAv1Dec-0.dll
> libsvtav1-1.8.0-1
> libsvtav1dec0-2.0.0-1
> 
> Im not sure why this happens.
> 
> Contrary to your idea,
> libsvtav1enc1_OBSOLETES="libsvtav1"
> libsvtav1enc1_REQUIRES="libsvtav1dec0"
> the followings happen as expected.
> Uninstall libsvtav1 1.8.0-1
> Install libsvtav1dec0 2.0.0-1
> Install libsvtav1enc1 1.8.0-2
> 
> Of cource,
> libsvtav1dec0_OBSOLETES=libsvtav1
> should be removed in this case.
> 
> What do you think?