[arch-general] arch-release
/etc/arch-release Anyone know what is meant to be in this file The guys on the gambas user list are writing some sort of script so users can identify details of their system in case of bugs etc, and i was asked if this file exists, which is does, but it is empty? ?any other unique arch identifiers.
On Wed, 2009-08-26 at 17:45 +1000, richard terry wrote:
/etc/arch-release
Anyone know what is meant to be in this file
The guys on the gambas user list are writing some sort of script so users can identify details of their system in case of bugs etc, and i was asked if this file exists, which is does, but it is empty?
?any other unique arch identifiers.
As Arch is a rolling release system, we decided to remove the file. But as tools use this file to identify Arch systems, we decided to keep the file, but make it empty. 2009.08 won't be 2009.08 as soon as you run pacman -Syu ;)
On Wed, 26 Aug 2009 09:56:13 +0200 Jan de Groot <jan@jgc.homeip.net> wrote:
On Wed, 2009-08-26 at 17:45 +1000, richard terry wrote:
/etc/arch-release
Anyone know what is meant to be in this file
The guys on the gambas user list are writing some sort of script so users can identify details of their system in case of bugs etc, and i was asked if this file exists, which is does, but it is empty?
?any other unique arch identifiers.
As Arch is a rolling release system, we decided to remove the file. But as tools use this file to identify Arch systems, we decided to keep the file, but make it empty.
maybe we should delete it. Did you mean 'identifying whether a system is arch linux' (which seems pretty pointless, you know when a system is arch linux) OR do you mean 'identify which "version" an arch system is' ? Assuming the latter, a better "system identification" would be something like `pacman -Q` Dieter
On Wednesday 26 August 2009 18:04:42 Dieter Plaetinck wrote:
On Wed, 26 Aug 2009 09:56:13 +0200
Jan de Groot <jan@jgc.homeip.net> wrote:
On Wed, 2009-08-26 at 17:45 +1000, richard terry wrote:
/etc/arch-release
Anyone know what is meant to be in this file
The guys on the gambas user list are writing some sort of script so users can identify details of their system in case of bugs etc, and i was asked if this file exists, which is does, but it is empty?
?any other unique arch identifiers.
As Arch is a rolling release system, we decided to remove the file. But as tools use this file to identify Arch systems, we decided to keep the file, but make it empty.
maybe we should delete it. Did you mean 'identifying whether a system is arch linux' (which seems pretty pointless, you know when a system is arch linux) OR do you mean 'identify which "version" an arch system is' ? Assuming the latter, a better "system identification" would be something like `pacman -Q`
Dieter
Thanks for the replies, me I didn't mean anything, they just asked me what was in the file. pacman -Q obviously not the answer, but whilst on that - is it possible to do a pacman -Q, save the output somewhere, then on another machine, just reverse the process? Would save me heaps of time putting a system back together as happened last week when i had to replace my HDD, taken me ages to 'remember' everything I had on it. Richard
On Wed, 26 Aug 2009 18:12:53 +1000 richard terry <rterry@pacific.net.au> wrote:
On Wednesday 26 August 2009 18:04:42 Dieter Plaetinck wrote:
On Wed, 26 Aug 2009 09:56:13 +0200
Jan de Groot <jan@jgc.homeip.net> wrote:
On Wed, 2009-08-26 at 17:45 +1000, richard terry wrote:
/etc/arch-release
Anyone know what is meant to be in this file
The guys on the gambas user list are writing some sort of script so users can identify details of their system in case of bugs etc, and i was asked if this file exists, which is does, but it is empty?
?any other unique arch identifiers.
As Arch is a rolling release system, we decided to remove the file. But as tools use this file to identify Arch systems, we decided to keep the file, but make it empty.
maybe we should delete it. Did you mean 'identifying whether a system is arch linux' (which seems pretty pointless, you know when a system is arch linux) OR do you mean 'identify which "version" an arch system is' ? Assuming the latter, a better "system identification" would be something like `pacman -Q`
Dieter
Thanks for the replies, me I didn't mean anything, they just asked me what was in the file.
pacman -Q obviously not the answer, but whilst on that - is it possible to do a pacman -Q, save the output somewhere, then on another machine, just reverse the process? Would save me heaps of time putting a system back together as happened last week when i had to replace my HDD, taken me ages to 'remember' everything I had on it.
Richard
`pacman -Qq > pkg.list` then on the other machine `sudo pacman -S $(cat pkg.list)`
On Wednesday 26 August 2009 03:19:30 am Nathan K. Bathory wrote:
pacman -Q obviously not the answer, but whilst on that - is it possible to do a pacman -Q, save the output somewhere, then on another machine, just reverse the process? Would save me heaps of time putting a system back together as happened last week when i had to replace my HDD, taken me ages to 'remember' everything I had on it.
Richard
To save the download time, if the machines are the same architecture:
`pacman -Qq > pkg.list` then on the other machine
(as root) rsync -uav username@oldmachine:/var/cache/pacman/pkg /var/cache/pacman
`sudo pacman -S $(cat pkg.list)`
If you rsync (or scp or move with a usb stick) the package files from the oldmachine to the newmachine before issuing the "sudo pacman -S $(cat pkg.list)`, then the install uses the local files and avoid the time required to download them. You can easily do a 10 minute install that way. -- David C. Rankin, J.D.,P.E. Rankin Law Firm, PLLC 510 Ochiltree Street Nacogdoches, Texas 75961 Telephone: (936) 715-9333 Facsimile: (936) 715-9339 www.rankinlawfirm.com
On 08/26/09 at 01:35pm, David C. Rankin wrote:
On Wednesday 26 August 2009 03:19:30 am Nathan K. Bathory wrote:
pacman -Q obviously not the answer, but whilst on that - is it possible to do a pacman -Q, save the output somewhere, then on another machine, just reverse the process? Would save me heaps of time putting a system back together as happened last week when i had to replace my HDD, taken me ages to 'remember' everything I had on it.
Richard
To save the download time, if the machines are the same architecture:
`pacman -Qq > pkg.list` then on the other machine
(as root) rsync -uav username@oldmachine:/var/cache/pacman/pkg /var/cache/pacman
`sudo pacman -S $(cat pkg.list)`
If you rsync (or scp or move with a usb stick) the package files from the oldmachine to the newmachine before issuing the "sudo pacman -S $(cat pkg.list)`, then the install uses the local files and avoid the time required to download them. You can easily do a 10 minute install that way.
as a small aside; after being corrected a few times on bbs, i now know that pacman -Qqe | grep -vx "$(pacman -Qqm)" > pkg.list and cat pkg.list | xargs pacman -S --noconfirm --needed work the best for this. list out only explicitly installed minus any foreign packages; then only install those that are needed (pull in your own deps). -- patrick brisbin
On Wednesday 26 August 2009 01:43:37 pm Patrick Brisbin wrote:
as a small aside; after being corrected a few times on bbs, i now know that
pacman -Qqe | grep -vx "$(pacman -Qqm)" > pkg.list
and
cat pkg.list | xargs pacman -S --noconfirm --needed
work the best for this. list out only explicitly installed minus any foreign packages; then only install those that are needed (pull in your own deps).
That's a keeper.... -- David C. Rankin, J.D.,P.E. Rankin Law Firm, PLLC 510 Ochiltree Street Nacogdoches, Texas 75961 Telephone: (936) 715-9333 Facsimile: (936) 715-9339 www.rankinlawfirm.com
On Wed, 26 Aug 2009 18:12:53 +1000 richard terry <rterry@pacific.net.au> wrote:
Thanks for the replies, me I didn't mean anything, they just asked me what was in the file.
pacman -Q obviously not the answer, but whilst on that - is it possible to do a pacman -Q, save the output somewhere, then on another machine, just reverse the process? Would save me heaps of time putting a system back together as happened last week when i had to replace my HDD, taken me ages to 'remember' everything I had on it.
of course. if you want to know the recommended commandline flags: this comes up on the wiki/forums frequently. In fact, part of my personal backup system is keeping a package list in svn instead of the actual files. (along with /etc and /home in version control, a generated list of installed ruby gems, etc etc), and i have a config file for aif which can reconstruct the entire system by bringing all parts together again in a smart way (I've blogged about this a few times as well, but it's still a work in progress for me) Dieter
On Wed, 2009-08-26 at 10:04 +0200, Dieter Plaetinck wrote:
maybe we should delete it. Did you mean 'identifying whether a system is arch linux' (which seems pretty pointless, you know when a system is arch linux) OR do you mean 'identify which "version" an arch system is' ? Assuming the latter, a better "system identification" would be something like `pacman -Q`
When /etc/arch-release exists, a script or application knows that it's running on archlinux. With just "pacman -Q" you won't prove it's archlinux, as my debian webserver with custom-compiled software also returns output there: I use pacman to manage my custom compiled software, no matter what distribution I use.
Am Mittwoch, den 26.08.2009, 09:56 +0200 schrieb Jan de Groot:
As Arch is a rolling release system, we decided to remove the file. But as tools use this file to identify Arch systems, we decided to keep the file, but make it empty.
2009.08 won't be 2009.08 as soon as you run pacman -Syu ;)
To far this we could maybe add a function to pacman, so that after every -Syu the unixtime gets written to this file. This would give us: * IMHO the highest version/release number a software/distribution ever have. * The individual content of this file then represent the nature of a rolling release. Ok, just kidding ;-) Gerhard
On Wed, 2009-08-26 at 10:40 +0200, Gerhard Brauer wrote:
Am Mittwoch, den 26.08.2009, 09:56 +0200 schrieb Jan de Groot:
As Arch is a rolling release system, we decided to remove the file. But as tools use this file to identify Arch systems, we decided to keep the file, but make it empty.
2009.08 won't be 2009.08 as soon as you run pacman -Syu ;)
To far this we could maybe add a function to pacman, so that after every -Syu the unixtime gets written to this file. This would give us: * IMHO the highest version/release number a software/distribution ever have. * The individual content of this file then represent the nature of a rolling release.
Ok, just kidding ;-)
And within 28 years it will overflow so we have a negative version number :P
On Wed, 26 Aug 2009 10:45:33 +0200 Jan de Groot <jan@jgc.homeip.net> wrote:
On Wed, 2009-08-26 at 10:40 +0200, Gerhard Brauer wrote:
Am Mittwoch, den 26.08.2009, 09:56 +0200 schrieb Jan de Groot:
As Arch is a rolling release system, we decided to remove the file. But as tools use this file to identify Arch systems, we decided to keep the file, but make it empty.
2009.08 won't be 2009.08 as soon as you run pacman -Syu ;)
To far this we could maybe add a function to pacman, so that after every -Syu the unixtime gets written to this file. This would give us: * IMHO the highest version/release number a software/distribution ever have. * The individual content of this file then represent the nature of a rolling release.
Ok, just kidding ;-)
And within 28 years it will overflow so we have a negative version number :P
maybe we should put the output of `pacman -Q | sha1sum` in /etc/arch-release. git style! :P Dieter
Am Mittwoch, den 26.08.2009, 10:52 +0200 schrieb Dieter Plaetinck:
maybe we should put the output of `pacman -Q | sha1sum` in /etc/arch-release. git style! :P
Neat! Or the percentage of our roadmap to world domination (BTW: i always missed this in Roadmap on Flyspray....)
Dieter
Gerhard
Gerhard Brauer schrieb:
Neat!
Or the percentage of our roadmap to world domination (BTW: i always missed this in Roadmap on Flyspray....)
It's not nearly complete. Right now, Arch runs on a very small percentage of computers world-wide. We need at least 20% until we can inject our world-domination-ware (wdm) into glibc. Also, the wdm is not nearly finished, I'll set up a public git repository soon so the community can help.
Am Mittwoch, den 26.08.2009, 10:45 +0200 schrieb Jan de Groot:
On Wed, 2009-08-26 at 10:40 +0200, Gerhard Brauer wrote:
To far this we could maybe add a function to pacman, so that after every -Syu the unixtime gets written to this file. This would give us: * IMHO the highest version/release number a software/distribution ever have. * The individual content of this file then represent the nature of a rolling release.
Ok, just kidding ;-)
And within 28 years it will overflow so we have a negative version number :P
I'm sure we will find a solution until this happens. Maybe we make 2037 our first "Release", so we would have an offset to add... ;-) Gerhard
On Wed, Aug 26, 2009 at 9:45 AM, Jan de Groot<jan@jgc.homeip.net> wrote:
On Wed, 2009-08-26 at 10:40 +0200, Gerhard Brauer wrote:
Am Mittwoch, den 26.08.2009, 09:56 +0200 schrieb Jan de Groot:
As Arch is a rolling release system, we decided to remove the file. But as tools use this file to identify Arch systems, we decided to keep the file, but make it empty.
2009.08 won't be 2009.08 as soon as you run pacman -Syu ;)
To far this we could maybe add a function to pacman, so that after every -Syu the unixtime gets written to this file. This would give us: * IMHO the highest version/release number a software/distribution ever have. * The individual content of this file then represent the nature of a rolling release.
Ok, just kidding ;-)
And within 28 years it will overflow so we have a negative version number :P
Of course the correct way of solving that would be to define an epoch for Arch, e.g. starting when Arch was first announced. Then we'd have to define a tick to be the time between package uploads to the master repo. (Correct counting of ticks can of course only happen from now on, but we still have to estimate the number of ticks since epoch to now, if for nothing else then for our sanity.) Then we modify the mirroring so that it is guaranteed to always hand out packages from the same tick (the current tick is established at start of download). Then Pacman must be modified to pick out the repos mentioned in /etc/pacman.conf mirroring the latest tick and only use those for the operation, it must of course also make sure that the mirror's tick is later than the system's. That sounds like a plan... oh, no, I forgot, this is Arch and not Debian ;-) /M -- Magnus Therning (OpenPGP: 0xAB4DFBA4) magnus＠therning．org Jabber: magnus＠therning．org http://therning.org/magnus identi.ca|twitter: magthe
On Wed, Aug 26, 2009 at 4:06 AM, Magnus Therning<magnus@therning.org> wrote:
On Wed, Aug 26, 2009 at 9:45 AM, Jan de Groot<jan@jgc.homeip.net> wrote:
On Wed, 2009-08-26 at 10:40 +0200, Gerhard Brauer wrote:
Am Mittwoch, den 26.08.2009, 09:56 +0200 schrieb Jan de Groot:
As Arch is a rolling release system, we decided to remove the file. But as tools use this file to identify Arch systems, we decided to keep the file, but make it empty.
2009.08 won't be 2009.08 as soon as you run pacman -Syu ;)
To far this we could maybe add a function to pacman, so that after every -Syu the unixtime gets written to this file. This would give us: * IMHO the highest version/release number a software/distribution ever have. * The individual content of this file then represent the nature of a rolling release.
Ok, just kidding ;-)
And within 28 years it will overflow so we have a negative version number :P
Of course the correct way of solving that would be to define an epoch for Arch, e.g. starting when Arch was first announced. Then we'd have to define a tick to be the time between package uploads to the master repo. (Correct counting of ticks can of course only happen from now on, but we still have to estimate the number of ticks since epoch to now, if for nothing else then for our sanity.) Then we modify the mirroring so that it is guaranteed to always hand out packages from the same tick (the current tick is established at start of download). Then Pacman must be modified to pick out the repos mentioned in /etc/pacman.conf mirroring the latest tick and only use those for the operation, it must of course also make sure that the mirror's tick is later than the system's.
That sounds like a plan... oh, no, I forgot, this is Arch and not Debian ;-)
Let's just put "1.0" in the file :) /me remembers the "Arch isn't stable, it's not even 1.0 yet!" arguments from the past
2009/8/26 Aaron Griffin <aaronmgriffin@gmail.com>:
On Wed, Aug 26, 2009 at 4:06 AM, Magnus Therning<magnus@therning.org> wrote:
On Wed, Aug 26, 2009 at 9:45 AM, Jan de Groot<jan@jgc.homeip.net> wrote:
On Wed, 2009-08-26 at 10:40 +0200, Gerhard Brauer wrote:
Am Mittwoch, den 26.08.2009, 09:56 +0200 schrieb Jan de Groot:
As Arch is a rolling release system, we decided to remove the file. But as tools use this file to identify Arch systems, we decided to keep the file, but make it empty.
2009.08 won't be 2009.08 as soon as you run pacman -Syu ;)
To far this we could maybe add a function to pacman, so that after every -Syu the unixtime gets written to this file. This would give us: * IMHO the highest version/release number a software/distribution ever have. * The individual content of this file then represent the nature of a rolling release.
Ok, just kidding ;-)
And within 28 years it will overflow so we have a negative version number :P
Of course the correct way of solving that would be to define an epoch for Arch, e.g. starting when Arch was first announced. Then we'd have to define a tick to be the time between package uploads to the master repo. (Correct counting of ticks can of course only happen from now on, but we still have to estimate the number of ticks since epoch to now, if for nothing else then for our sanity.) Then we modify the mirroring so that it is guaranteed to always hand out packages from the same tick (the current tick is established at start of download). Then Pacman must be modified to pick out the repos mentioned in /etc/pacman.conf mirroring the latest tick and only use those for the operation, it must of course also make sure that the mirror's tick is later than the system's.
That sounds like a plan... oh, no, I forgot, this is Arch and not Debian ;-)
Let's just put "1.0" in the file :)
/me remembers the "Arch isn't stable, it's not even 1.0 yet!" arguments from the past
What about putting date when pacman -Syu was run for a last time in that file? It would still suffer from lag when using mirrors but I guess it should be accurate enough. Lukas
2009/8/26 Lukáš Jirkovský <l.jirkovsky@gmail.com>:
What about putting date when pacman -Syu was run for a last time in that file? It would still suffer from lag when using mirrors but I guess it should be accurate enough.
I don't think anyone is going to really put something in that file, so don't hold your breath. The point it that there's no real usefulness of any information in that file. Only the existence of the file is needed, so apps (e.g. VirtualBox) can check for it to know they are running in Arch. -- Roman Kyrylych (Роман Кирилич)
Am Wed, 26 Aug 2009 19:25:07 +0300 schrieb Roman Kyrylych <roman.kyrylych@gmail.com>:
2009/8/26 Lukáš Jirkovský <l.jirkovsky@gmail.com>:
What about putting date when pacman -Syu was run for a last time in that file? It would still suffer from lag when using mirrors but I guess it should be accurate enough.
I don't think anyone is going to really put something in that file, so don't hold your breath. The point it that there's no real usefulness of any information in that file. Only the existence of the file is needed, so apps (e.g. VirtualBox) can check for it to know they are running in Arch.
It's also nice to have for your .$SHELLrc to activate distribution-specific aliases (think package manager for example). /etc/gentoo-release is part of sys-apps/baselayout and contains it's version number: # cat /etc/gentoo-release Gentoo Base System release 2.0.1 So perhaps the version of core/filesystem might be a good fit. (It's not in any way accurate but mirrors the practice of another popular rolling-release distro ;)) --
participants (13)
-
Aaron Griffin
-
Alexander Duscheleit
-
David C. Rankin
-
Dieter Plaetinck
-
Gerhard Brauer
-
Jan de Groot
-
Lukáš Jirkovský
-
Magnus Therning
-
Nathan K. Bathory
-
Patrick Brisbin
-
richard terry
-
Roman Kyrylych
-
Thomas Bächler