How can one investigate the release candidate (rc) from qubes?

[Luisames]

Qubes OS version:

• Qubes 4.0

General notes:

• I looked inside /etc/issue and /etc/qubes-release, but there isn't written the rc.

[unman]

I think this is one of those things not done. If I remember my installer still had rc4 on it.
You can check the versions of packages in dom0, or (of course) check for updates.

[unman]

I think this is one of those things not done. If I remember my installer still had rc4 on it.
You can check the versions of packages in dom0, or (of course) check for updates.

[marmarek]

Yes, this is one of those things impossible currently. This is especially tricky because there are multiple places where packages are installed. For example if you install rc4, then install all updates, you'll effectively have rc5. But if you install only dom0 updates, but not templates, then half of your system is rc4 and half rc5. So a single information "Qubes OS 4.0-rc5" is useless there. Unless we find some clever method for solving this problem, I think it's better to not show misleading information.

[marmarek]

Yes, this is one of those things impossible currently. This is especially tricky because there are multiple places where packages are installed. For example if you install rc4, then install all updates, you'll effectively have rc5. But if you install only dom0 updates, but not templates, then half of your system is rc4 and half rc5. So a single information "Qubes OS 4.0-rc5" is useless there. Unless we find some clever method for solving this problem, I think it's better to not show misleading information.

[andrewdavidwong]

Closing this for now as "won't fix" (technically, "can't fix"). If you believe this is a mistake, or if anyone has a clever solution, please leave a comment, and we'll be happy to reopen this. Thank you.

[andrewdavidwong]

Closing this for now as "won't fix" (technically, "can't fix"). If you believe this is a mistake, or if anyone has a clever solution, please leave a comment, and we'll be happy to reopen this. Thank you.

[andrewdavidwong]

@marmarek, I propose changing the string to:

Qubes OS 4.0 (release candidate)

(I.e., do not specify the RC number.)

[andrewdavidwong]

@marmarek, I propose changing the string to:

Qubes OS 4.0 (release candidate)

(I.e., do not specify the RC number.)

[andrewdavidwong]

@marmarek: I'm seeing a lot of reports from 4.0 users who are confused about whether they've upgraded from RC 4 to RC 5 or not. Can we provide a list of packages (or instructions for finding such a list) for dom0 and templates that will allow a user to check whether they've upgraded or not?

[andrewdavidwong]

@marmarek: I'm seeing a lot of reports from 4.0 users who are confused about whether they've upgraded from RC 4 to RC 5 or not. Can we provide a list of packages (or instructions for finding such a list) for dom0 and templates that will allow a user to check whether they've upgraded or not?

[andrewdavidwong]

@marmarek: The most common problem I'm seeing (if this is, in fact, what's happening -- maybe it's actually something else) is that the instructions direct the user to upgrade using qubes-dom0-update with the testing repos, but users who already did that between the time when the packages were made available and the time when the announcement was published (or when they saw it) do not realize that they've already upgraded. So, when they see "No updates available," they think something has gone wrong.

[andrewdavidwong]

@marmarek: The most common problem I'm seeing (if this is, in fact, what's happening -- maybe it's actually something else) is that the instructions direct the user to upgrade using qubes-dom0-update with the testing repos, but users who already did that between the time when the packages were made available and the time when the announcement was published (or when they saw it) do not realize that they've already upgraded. So, when they see "No updates available," they think something has gone wrong.

[ecdsa521]

If you write the rc # into eg. /etc/qubes-release it will be quite obvious reading it in dom0 will mean dom0 is at this version, and reading from template will mean template is at this version. Isn't this most elegant and also show if they are out of sync somehow (because I forgot to upgrade one or the other)?

Don't need to check if entire system is at rcX, because as was said it can be misleading. But checking each component should be doable.

[ecdsa521]

If you write the rc # into eg. /etc/qubes-release it will be quite obvious reading it in dom0 will mean dom0 is at this version, and reading from template will mean template is at this version. Isn't this most elegant and also show if they are out of sync somehow (because I forgot to upgrade one or the other)?

Don't need to check if entire system is at rcX, because as was said it can be misleading. But checking each component should be doable.

[unman]

Well it's already trivial to check the package versions, but I dont think it's so easy to check the rc version. At what stage will packages from Testing combine to form an rc?
It appears that users are keen to use the Testing repos but (for whatever reason) don't realise that rc5 just IS rc4+updates from Testing. And then continued use of the Testing repos will take things further away from vanilla rc5.
I favour the suggestion from @andrewdavidwong of providing some minimal version number for one or more key packages as an identifier.

[unman]

Well it's already trivial to check the package versions, but I dont think it's so easy to check the rc version. At what stage will packages from Testing combine to form an rc?
It appears that users are keen to use the Testing repos but (for whatever reason) don't realise that rc5 just IS rc4+updates from Testing. And then continued use of the Testing repos will take things further away from vanilla rc5.
I favour the suggestion from @andrewdavidwong of providing some minimal version number for one or more key packages as an identifier.