On Wed, Aug 26, 2009 at 4:06 AM, Magnus Therning<magnus@xxxxxxxxxxxx> wrote: > On Wed, Aug 26, 2009 at 9:45 AM, Jan de Groot<jan@xxxxxxxxxxxxxx> 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
