Identifying the Arch Linux release level

andymaier · 2016-01-04 20:44:38

Hi.
I do understand that Arch Linux has a rolling release concept, and therefore has no release number attached.

However, it seems to me that there are several occasions where it would be helpful being able to identify the current "level" of Arch Linux. I do not mean the Linux kernel release (available via uname -r), but the update level of the entire system.

This is useful for these reasons (just some that came to mind, I suppose there are more):

Naming the release level that introduced a feature, or that had a bug or that fixed a bug.
Specifying dependencies on a minimum release level in distribution-agnostic packages (e.g. Python/Perl/Ruby/... packages).
Setting up a specific release level of the past for testing.

Is there something in the current Arch Linux that allows identifying the release level?
Maybe the date of the last system-wide update?

Andy

graysky · 2016-01-04 20:49:26

I do not believe so; as you pointed out, it is a rolling release so this concept doesn't apply. The live media is the closes thing, but again, you write out the 2016.01.01...iso and boot to it, as soon as you update it, it is no longer that snapshot.

jasonwryan · 2016-01-04 20:52:18

How would this work? You have package versions for the kernel, systemd, coreutils, etc... You just end up with a whole list of different versions; none of which actually constitute a "release" (people with [testing] enabled, for example, will have different versions of [core] packages running, for example).

The only thing you should be concerned about is whether or not your system (ie., the specific set of packages that constitute your machine) is up-to-date.

You can always retrieve the date and time of your last full update from pacman's log, if that is what you are looking for.

Moving to Arch discussion.

Head_on_a_Stick · 2016-01-04 21:02:42

# pacman -Syu|wc -l

EDIT: This is a facetious post BTW, the point being to `-Syu` and carefully read the output -- this will tell you exactly where you system is in respect of upgrade status.

Last edited by Head_on_a_Stick (2016-01-04 21:11:35)

Trilby · 2016-01-04 21:12:18

I don't see how this would be even remotely useful. Specifically:

andymaier wrote:

Naming the release level that introduced a feature, or that had a bug or that fixed a bug.
Specifying dependencies on a minimum release level in distribution-agnostic packages (e.g. Python/Perl/Ruby/... packages).
Setting up a specific release level of the past for testing.

1) Reporting to upstream that there was an error introduced in vim with archlinux release 2016.01.04.0845 would not be very meaningful. On the other hand, reporting the error in version 7.4.944 would be meaningful.

2) How would an archlinux-specific release level help in specifying distro-agnostic depenencies?? Packages do not depend on a distro release, they depend on other packages each of which have version numbers. So a vim plugin should not depend on archlinux >= 2016.01.04.0845, but it might depend on vim >= 7.4.944.

3) What does this one even mean? You can use the arch rollback machine to downgrade to packages from a particular date already.

So again, release numbers would be completely meaningless, package version numbers are useful.

Scimmia · 2016-01-04 23:01:03

Someone said something a while back that I think sums things up very well. There are two version of Arch Linux. Up to date and out of date. Nothing more.

Brcher · 2016-02-17 23:48:14

Since it is rolling release, it ought to be continuous, or as close to it as we can get.
How about:
sudo pacman -Syu && date +%s%N

jasonwryan · 2016-02-17 23:55:00

pacman's log is date stamped...

clfarron4 · 2016-02-18 01:19:46

jasonwryan wrote:

pacman's log is date stamped...

Correlating that with an ArchLinux Rollback Machine and we might be onto something here.

marcus-s · 2016-02-19 14:07:21

Since Arch is a rolling release, it might be best to provide a date for when a certain action happened (command issued, error came up, log file generated, etc.). I'm not familiar with the maintenance of the packages, but I can imagine that there is some kind of log which describes which version of which package was available at the time of posting a certain post.

For example: "State of Arch Linux from DD-MM-YYYY. I attempted to run foo from package bar and it gave me the message below in the console... any pointers?"

// EDIT:
I realize that this might be a flawed approach provided that not all people keep all the packages up to date all the time. This approach does assume all packages to be up-to-date on the specific machine where the issue is described.

Last edited by marcus-s (2016-02-19 14:12:46)

Trilby · 2016-02-19 14:16:49

marcus-s wrote:

Since Arch is a rolling release, it might be best to provide a date for when a certain action happened ... I can imagine that there is some kind of log which describes which version of which package was available at the time of posting a certain post.

There certainly is. But why would you expect the upstream devs to wade through our distro-specific information to figure out what version of their software we were using on that day rather than just providing them with the version in the first place. Again:

Trilby wrote:

1) Reporting to upstream that there was an error introduced in vim with archlinux release 2016.01.04.0845 would not be very meaningful. On the other hand, reporting the error in version 7.4.944 would be meaningful.

I have a couple of bits of software that are used in multiple distros. If someone reports an error with v1.32 that means something to me. If they report an error in git commit #23418 that also means something to me. If they say that the problem appeared with their distro's vesion Wincing Wackjob I don't have a damned clue what that means, and I'd have to go digging through an unfamiliar distro's websites hoping to find where they might show which version of my software was packaged for Wincing Wackjob. In most cases I wouldn't bother: I'd assume the person reporting the error is either too selfish or to stupid to know how to provide useful information - in either case little good would come from interacting with them. If I was generous, I'd simply tell them to include which version the error was with.

Arch Linux

#1 2016-01-04 20:44:38

Identifying the Arch Linux release level

#2 2016-01-04 20:49:26

Re: Identifying the Arch Linux release level

#3 2016-01-04 20:52:18

Re: Identifying the Arch Linux release level

#4 2016-01-04 21:02:42

Re: Identifying the Arch Linux release level

#5 2016-01-04 21:12:18

Re: Identifying the Arch Linux release level

#6 2016-01-04 23:01:03

Re: Identifying the Arch Linux release level

#7 2016-02-17 23:48:14

Re: Identifying the Arch Linux release level

#8 2016-02-17 23:55:00

Re: Identifying the Arch Linux release level

#9 2016-02-18 01:19:46

Re: Identifying the Arch Linux release level

#10 2016-02-19 14:07:21

Re: Identifying the Arch Linux release level

#11 2016-02-19 14:16:49

Re: Identifying the Arch Linux release level

Board footer