Hello,
While updating multiple Alpine edge systems that hadn't been updated
for a few days, I noticed that x264-libs was being downgraded on one
of them. As there are no logging for package operations, I can't tell
what precisely happened, but running 'apk info x264-libs' shows the
installed version as x264-libs-0.164_git20220602-r0 which is the
correct latest one.
Can anyone explain what happened?
Best regards,
Mogens Jensen
Hi,
we have changed the version number from YYYYMMDD to 0.ABI_gitYYYYMMDD, i.e. to include the ABI version in pkgver. Now it’s more clear when the dependent packages should be rebuilt/upgraded.
https://gitlab.alpinelinux.org/alpine/aports/-/commit/a180db09f3b271548ca42478f2c6d27c2abe2f70
Jakub
On 7/5/22 10:50 PM, Mogens Jensen wrote:
> Hello,> > While updating multiple Alpine edge systems that hadn't been updated> for a few days, I noticed that x264-libs was being downgraded on one> of them. As there are no logging for package operations, I can't tell> what precisely happened, but running 'apk info x264-libs' shows the> installed version as x264-libs-0.164_git20220602-r0 which is the> correct latest one.> > Can anyone explain what happened?> > Best regards,> Mogens Jensen>
On Tue Jul 5, 2022 at 11:40 PM CEST, Jakub Jirutka wrote:
> Hi,>> we have changed the version number from YYYYMMDD to 0.ABI_gitYYYYMMDD, i.e. to include the ABI version in pkgver. Now it’s more clear when the dependent packages should be rebuilt/upgraded.
we did do that in january - but the recent 163->164 abiver upgrade was
indeed a few days ago, and this was a recent update..
granted, without any logs it's impossible to know for sure what
happened, and there doesn't seem to be an actual issue.
>> https://gitlab.alpinelinux.org/alpine/aports/-/commit/a180db09f3b271548ca42478f2c6d27c2abe2f70>> Jakub>> On 7/5/22 10:50 PM, Mogens Jensen wrote:> > Hello,> > > > While updating multiple Alpine edge systems that hadn't been updated> > for a few days, I noticed that x264-libs was being downgraded on one> > of them. As there are no logging for package operations, I can't tell> > what precisely happened, but running 'apk info x264-libs' shows the> > installed version as x264-libs-0.164_git20220602-r0 which is the> > correct latest one.> > > > Can anyone explain what happened?> > > > Best regards,> > Mogens Jensen> >
Indeed there is no issue with the functionality of the system, but
I do like to deduce a hypothesis when "weird" stuff happens on the
systems I manage.
If I understand correctly, the only scenario where apk could
"downgrade" is if the previous x264-libs pkgver was 20210613 or lower?
If version 20210613-r0 was installed when the following was committed:
community/x264: change version number to include ABI version
https://gitlab.alpinelinux.org/alpine/aports/-/commit/a180db09f3b271548ca42478f2c6d27c2abe2f70
Is it 100% sure that the package should have been upgraded on the
system after that? Of course, normally a new version in pkgver would
make apk upgrade the package, but maybe because of the change in
version number scheme, the pkgrel should also have been set to 1 for
apk to upgrade?
I have tried to manually install x264-libs-20210613-r0.apk on an edge
system with all repositories enabled, remove the string appended to
package name in /etc/apk/world and run "apk update && apk upgrade -v".
The result is that x264-libs is NOT upgraded. Even after running
"apk add -v --upgrade x264-libs" apk still shows no updates.
With the following commit, pgrel was set to 1:
community/x264: enable lto
https://gitlab.alpinelinux.org/alpine/aports/-/commit/eecb4709387b5c56b5e4dfc8d28cf4923c754b24
I know for a fact that this was the version installed on the systems I
updated yesterday, that did not "downgrade" x264-libs. So maybe last
time I updated these system, it was in the short window while
x264-libs-0.163_git20210613-r1.apk was available on the mirror, which
made apk upgrade from x264-libs-20210613-r0, that's why no "downgrade"
happened on these yesterday.
I see that ffmpeg4-libs-4.4.2-r2 and ffmpeg-libs-5.0.1-r3 depends on
x264-libs-0.164_git20220602-r0, so maybe updating ffmpeg4-libs and
ffmpeg-libs was the cause of x264-libs-20210613-r0 finally being
upgraded to x264-libs-0.164_git20220602-r0 which caused the
"Downgrading" message on this single system.
Does that sounds plausible?
I know there have been some work on adding log file functionality to
apk, does anyone know the status of that?
Best regards,
Mogens Jensen
On Wed Jul 6, 2022 at 2:48 PM CEST, Mogens Jensen wrote:
> Indeed there is no issue with the functionality of the system, but> I do like to deduce a hypothesis when "weird" stuff happens on the> systems I manage.
me too, but without actual logs all we can do is speculate, which is not
very 'exciting'. (not meant in any negative way)
>> If I understand correctly, the only scenario where apk could> "downgrade" is if the previous x264-libs pkgver was 20210613 or lower?>> If version 20210613-r0 was installed when the following was committed:>> community/x264: change version number to include ABI version> https://gitlab.alpinelinux.org/alpine/aports/-/commit/a180db09f3b271548ca42478f2c6d27c2abe2f70>> Is it 100% sure that the package should have been upgraded on the> system after that? Of course, normally a new version in pkgver would> make apk upgrade the package, but maybe because of the change in> version number scheme, the pkgrel should also have been set to 1 for> apk to upgrade?
neither of those would upgrade. 20210613 -> 0.163 is a downgrade
regardless of pkgrel. but this was 5 months ago, and you said
recently; so i assumed it was 0.163->0.164.
if you actually had 20210613, then yes, it looks like a downgrade. this
is prevented unless you pass -a to apk upgrade, but -a is already
required between release branches (to swap all the repository markings),
so there is no issue for version upgrades.
there is an exception, where apk will still pull in downgrades to
satisfy dependencies for other things (i forget the specifics) and this
specific library is quite needed so, it probably did it regardless of
-a.
(and on edge, it's expected people somewhat know what they're doing and
run -a at least sometimes anyway.)
>> I have tried to manually install x264-libs-20210613-r0.apk on an edge> system with all repositories enabled, remove the string appended to> package name in /etc/apk/world and run "apk update && apk upgrade -v".> The result is that x264-libs is NOT upgraded. Even after running> "apk add -v --upgrade x264-libs" apk still shows no updates.
this would not be possible as the package does not exist in any
repository anymore. even if you had it in cache (with a cache enabled)
it would not be present in any APKINDEX (unless you had a 3.15
repository or somesuch configured, i suppose?), so that simply doesn't
exist.
>> With the following commit, pgrel was set to 1:>> community/x264: enable lto> https://gitlab.alpinelinux.org/alpine/aports/-/commit/eecb4709387b5c56b5e4dfc8d28cf4923c754b24>> I know for a fact that this was the version installed on the systems I> updated yesterday, that did not "downgrade" x264-libs. So maybe last> time I updated these system, it was in the short window while> x264-libs-0.163_git20210613-r1.apk was available on the mirror, which> made apk upgrade from x264-libs-20210613-r0, that's why no "downgrade"> happened on these yesterday.
i'm confused what you're saying here. how many upgrades happened and
what versions do you think were between each one? you say 'this' was the
version installed (0.163-r1), but it was 'upgraded from' 20210613, but
then there was more stuff that was the actual 'downgrade' and this
wasn't it.
the commit changing to 0.163 still had the same soname (.so.163) and so
wouldn't be upgraded to without -a (as it's a downgrade but everything
is still satisfied). once 0.164 was made things 'want' 0.164 so it gets
upgraded to.
>> I see that ffmpeg4-libs-4.4.2-r2 and ffmpeg-libs-5.0.1-r3 depends on> x264-libs-0.164_git20220602-r0, so maybe updating ffmpeg4-libs and> ffmpeg-libs was the cause of x264-libs-20210613-r0 finally being> upgraded to x264-libs-0.164_git20220602-r0 which caused the> "Downgrading" message on this single system.
based on the above statement combined with this one there was a single
upgrade in a single step considered a downgrade, but you make it sound
like multiple because you say the 0.163-r1 was 'definitely' the one
installed but here it's 0.164 so if it triggered it it would.. not be
0.163? maybe you should draw a graph as i can't follow what you're
saying.
>> Does that sounds plausible?
if you had 190284091284bunchofnumbers and the new version is 0.
(smaller), then yes, it's a downgrade.
>> I know there have been some work on adding log file functionality to> apk, does anyone know the status of that?
iirc it's added to apk3
https://gitlab.alpinelinux.org/alpine/apk-tools/-/commit/646c834492a419a96b4032c230e842d27f87e997>> Best regards,> Mogens Jensen
Sorry for any confusion, I will try to explain better and thanks
for the effort to help. First an overview of my problem:
I maintain 8 Alpine edge workstations in a lab. 7 for students and 1
for instructor. The 7 student systems was updated last time on Jun 30.
I don't remember when the instructor system was updated, maybe a few
days before Jun 30.
On Jul 05 i go to the lab and run "apk update && apk upgrade -v" on
the 7 student systems. Everything seems normal. I then do the same on
the instructor system, but here I see a "Downgrading" message while
x264-libs was updating. However, the messages rolled off the screen
before I could read the version numbers. I check the Alpine commit log
and see that x264-libs should not have been downgraded recently, and
because of paranoid nature, I'm trying to find out what most likely
happened.
I do understand that nothing was actually downgraded, apk only prints
this because of the change in version number scheme as Jakub
explained. So "Downgrading" will be shown at the point where x264-libs
with old scheme is upgraded to a version with new scheme.
However, the scheme was changed on 2022-01-19 so I wonder why the new
x264-libs package was first now installed on the instructor system,
and why the student systems already had a x264-libs package installed
with the new version scheme. Ultimately if there could be something
malicious going on.
When I write upgrade/update/installed, I mean what happens when
running "apk update && apk upgrade -v".
On Wednesday, July 6th, 2022 at 1:02 PM, alice <alice@ayaya.dev> wrote:
> (and on edge, it's expected people somewhat know what they're doing and> run -a at least sometimes anyway.)
Yes, I do run that, mostly at the same time when new stable Alpine
versions are released. However, I probably did not do it last time.
> > I have tried to manually install x264-libs-20210613-r0.apk on an edge> > system with all repositories enabled, remove the string appended to> > package name in /etc/apk/world and run "apk update && apk upgrade -v".> > The result is that x264-libs is NOT upgraded. Even after running> > "apk add -v --upgrade x264-libs" apk still shows no updates.>> this would not be possible as the package does not exist in any> repository anymore. even if you had it in cache (with a cache enabled)> it would not be present in any APKINDEX (unless you had a 3.15> repository or somesuch configured, i suppose?), so that simply doesn't> exist.
This was an experiment I did on a freshly installed edge system, just
to see what would happen if 20210613-r0 was installed on the system
while 0.164_git20220602-r0 is available in the repository, to try and
simulate the events from the lab.
I downloaded the x264-libs-20210613-r0.apk from v3.15 community
repository and installed it manually. If just running
"apk update && apk upgrade -v" afterwards, then apk will just display
this:
OK: 186 MiB in 147 packages
Of course if I run "apk update && apk upgrade -v -a" then apk will
install the newest version:
(1/1) Downgrading x264-libs (20210613-r0 -> 0.164_git20220602-r0)
But I did not use the -a flag, while updating the instructor system.
> > With the following commit, pgrel was set to 1:> >> > community/x264: enable lto> > https://gitlab.alpinelinux.org/alpine/aports/-/commit/eecb4709387b5c56b5e4dfc8d28cf4923c754b24> >> > I know for a fact that this was the version installed on the systems I> > updated yesterday, that did not "downgrade" x264-libs. So maybe last> > time I updated these system, it was in the short window while> > x264-libs-0.163_git20210613-r1.apk was available on the mirror, which> > made apk upgrade from x264-libs-20210613-r0, that's why no "downgrade"> > happened on these yesterday.>> i'm confused what you're saying here. how many upgrades happened and> what versions do you think were between each one? you say 'this' was the> version installed (0.163-r1), but it was 'upgraded from' 20210613, but> then there was more stuff that was the actual 'downgrade' and this> wasn't it.
On the 7 student systems I know that on Jul 05 before I started to
update the systems, x264-libs-0.163_git20210613-r1 was installed on
those, because I first test updates on a virtual machine identical to
those systems, and I still had a snapshot of the VM from last time,
so I could check what was installed. So on the student systems
x264-libs-0.163_git20210613-r1 was installed for some reason.
My theory was that the student systems was updated in the short window
where x264-libs-0.163_git20210613-r1 was available
(0.164_git20220602-r0 was uploaded to repositories on the same day),
and because pkgrel was set to 1, the upgrade from x264-libs with old
version scheme was initiated at that point in time.
The instructor system printed the "Downgrading" message, so therefore
the previous version before upgrading the system must have been
20210613-r0.
My theory was that because latest ffmpeg-libs and ffmpeg4-libs depends
on x264-libs-0.164_git20220602-r0, upgrading those packages would
initiate the upgrade of 20210613-r0 on the instructor system. I have
made a test that somewhat resembles this:
# apk add -v x264-libs-20210613-r0.apk
(1/1) Installing x264-libs (20210613-r0)
OK: 148 packages, 908 dirs, 10280 files, 190 MiB
# apk add -v ffmpeg4-libs
[..]
(34/39) Installing vulkan-loader (1.3.216.0-r0)
(35/39) Downgrading x264-libs (20210613-r0 -> 0.164_git20220602-r0)
(36/39) Installing numactl (2.0.14-r0)
(37/39) Installing x265-libs (3.5-r3)
(38/39) Installing xvidcore (1.3.7-r1)
(39/39) Installing ffmpeg4-libs (4.4.2-r2)
Above was my try to explain why the student systems could have
0.163_git20210613-r1 installed, but instructor system only had
20210613-r0 and why it was first now updated to latest version.
Hope that made more sense.
Best regards,
Mogens Jensen
yeah, i think you got it. the instructor system must've not had an -a passed for a while, and apk kept the 'big' version, up until the 'downgraded' version was forcefully pulled in due to the new soname (164). solved :)
Case closed. Thanks.
It's now full clear what happend. The theory about instructor system
is most likely correct. However, I was wrong about student systems,
as you said, soname was still the same with
x264-libs-0.163_git20210613-r1 so if the installed version was
actually x264-libs-20210613-r0 it would not upgrade without -a. The
pkgrel dosen't matter.
What actually happened was that on 2022-03-09 ffmpeg-libs was added to
firefox depends. This made student systems install x264-libs which was
not present before. The version installed was
x264-libs-0.163_git20210613-r0. On 2022-06-30 by coincidence the
student systems updated in the few hours were
x264-libs-0.163_git20210613-r1 was available in the repository. Of
course now pkgrel matter, so the package was upgraded. On 2022-07-05 I
update the systems again and 0.164_git20220602-r0 was installed.
There was never a "Downgrading" message on the student systems,
because the first version of x264-libs installed was after the version
scheme change.
On instructor system, ffmpeg-libs was already installed long ago for
other reasons, so the version of x264-libs was from before the version
scheme change. This is why only this system displayed the
"Downgrading" message.
To avoid this situation in the future:
"apk upgrade -v -s"
or
"apk upgrade -v | tee -a system-update-$(date +"%F").log"
And of course don't forget "-a" option too long.
:)
Best regards,
Mogens Jensen