Pacman

Historical bug tracker for the Pacman package manager.

The pacman bug tracker has moved to gitlab:
https://gitlab.archlinux.org/pacman/pacman/-/issues

This tracker remains open for interaction with historical bugs during the transition period. Any new bugs reports will be closed without further action.
Tasklist

FS#2234 - revision system: any logic behind it?

Attached to Project: Pacman
Opened by Nikos Kouremenos (zeppelin) - Saturday, 19 February 2005, 15:30 GMT
Task Type Support Request
Category
Status Closed
Assigned To No-one
Architecture not specified
Severity Very Low
Priority Normal
Reported Version 0.7 Wombat
Due in Version Undecided
Due Date Undecided
Percent Complete 0%
Votes 0
Private No

Details

hello. I'm using testing and I like it.
I have seen this in the past, and recently also donating some money for server costs. I 'm trying to understand the hidden logic behind this scenario:

xorg goes to testing
so -1

xorg (the same package) goes to current

will it still continue to be -1 (as it has to cause the package didn't change) or the same package will be called -2 and uploaded, so we [the testing repo runners], will have to download that one again, eventhough it's the same.

If no changes what so ever, and you put -2, then I really don't understand why you spent so much bandwidth without a real cause. If it would not change, then have a nice day and thanks for explaining..
This task depends upon

Closed by  Jan de Groot (JGC)
Sunday, 20 February 2005, 13:20 GMT
Reason for closing:  Not a bug
Comment by Jan de Groot (JGC) - Sunday, 20 February 2005, 00:44 GMT
We usually move from testing to current without changing version numbers, but in case of xorg a different host.def was used to compile xorg. This recompile was required to fix an outstanding bug. Since -1 was ok, the -2 went directly into current.
Comment by Nikos Kouremenos (zeppelin) - Sunday, 20 February 2005, 11:19 GMT
oh ok. so there's some logic. ok nice to hear it. thaks and close this :)
thanks Jan

Loading...