Bug#346179: debsecan: doesn't seem to correctly grok ~ in version number
On Sat, Jan 14, 2006 at 03:14:55PM +0100, Florian Weimer wrote: > I'm inclined to handle ~ versions only if python-apt is installed. > Would this be acceptable to you? I think so. Please have your package suggest python-apt and emit a meaningful warning if python-apt is not found and a ~ version is encountered. Greetings Marc -- - Marc Haber | "I don't trust Computers. They | Mailadresse im Header Mannheim, Germany | lose things."Winona Ryder | Fon: *49 621 72739834 Nordisch by Nature | How to make an American Quilt | Fax: *49 621 72739835 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#346179: debsecan: doesn't seem to correctly grok ~ in version number
Package: debsecan Version: 0.3.4 Severity: normal Hi, debsecan complains "invalid version 1.2.9-1~zg1 of package $PACKAGE" The version is, however, correct. This should be fixed. Greetings Marc -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable'), (500, 'stable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.15-zgsrv Locale: LANG=C, LC_CTYPE=de_DE (charmap=ISO-8859-1) Versions of packages debsecan depends on: ii debconf [debconf-2.0] 1.4.67 Debian configuration management sy ii python2.3.5-3An interactive high-level object-o Versions of packages debsecan recommends: ii cron 3.0pl1-92 management of regular background p ii exim4-daemon-light [mail-tran 4.60-1 lightweight exim MTA (v4) daemon -- debconf information excluded -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#346179: debsecan: doesn't seem to correctly grok ~ in version number
* Marc Haber: > debsecan complains > "invalid version 1.2.9-1~zg1 of package $PACKAGE" > > The version is, however, correct. This should be fixed. How? Is there an official description of the ~ semantics? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#346179: debsecan: doesn't seem to correctly grok ~ in version number
On Fri, Jan 06, 2006 at 10:55:28AM +0100, Florian Weimer wrote: > * Marc Haber: > > debsecan complains > > "invalid version 1.2.9-1~zg1 of package $PACKAGE" > > > > The version is, however, correct. This should be fixed. > > How? Is there an official description of the ~ semantics? I didn't find any official description short of #150739 and #93386. The semantics are, that 1.0-1~1 is smaller than 1.0-1 but greater than 1.0-0. This is very useful for creation of backport version numbers. Greetings Marc -- - Marc Haber | "I don't trust Computers. They | Mailadresse im Header Mannheim, Germany | lose things."Winona Ryder | Fon: *49 621 72739834 Nordisch by Nature | How to make an American Quilt | Fax: *49 621 72739835 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#346179: debsecan: doesn't seem to correctly grok ~ in version number
* Marc Haber: > On Fri, Jan 06, 2006 at 10:55:28AM +0100, Florian Weimer wrote: >> * Marc Haber: >> > debsecan complains >> > "invalid version 1.2.9-1~zg1 of package $PACKAGE" >> > >> > The version is, however, correct. This should be fixed. >> >> How? Is there an official description of the ~ semantics? > > I didn't find any official description short of #150739 and #93386. > The semantics are, that 1.0-1~1 is smaller than 1.0-1 but greater than > 1.0-0. And this does indeed result in a linear ordering? What happens if there are multiple ~? > This is very useful for creation of backport version numbers. Uhm, but this would mean that a bug which is fixed in 1.2.9-1 would still be considered present in 1.2.9-1~zg1 because that version is smaller. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#346179: debsecan: doesn't seem to correctly grok ~ in version number
On Fri, Jan 06, 2006 at 12:33:09PM +0100, Florian Weimer wrote: > * Marc Haber: > > I didn't find any official description short of #150739 and #93386. > > The semantics are, that 1.0-1~1 is smaller than 1.0-1 but greater than > > 1.0-0. > > And this does indeed result in a linear ordering? Probably. > What happens if there are multiple ~? They are processed in order. dpkg --compare-versions handles ~ correctly. > > This is very useful for creation of backport version numbers. > > Uhm, but this would mean that a bug which is fixed in 1.2.9-1 would > still be considered present in 1.2.9-1~zg1 because that version is > smaller. Well, there are many different uses of the construct. I usually use it for backports to make sure that the backport replaces the package that is currently installed, but is replaced by the backport source version once it reaches the distribution in use. For example: At time A, unstable has foo_1.2.9-2, while stable has foo_1.2.9-1. If my backport is thus named foo_1.2.9-2~zg1, it will replace 1.2.9-1 on stable, which is intended. When next stable releases and foo_1.2.9-2 reaches stable, this version replaces the backport, which is also intended. Greetings Marc -- - Marc Haber | "I don't trust Computers. They | Mailadresse im Header Mannheim, Germany | lose things."Winona Ryder | Fon: *49 621 72739834 Nordisch by Nature | How to make an American Quilt | Fax: *49 621 72739835 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#346179: debsecan: doesn't seem to correctly grok ~ in version number
* Marc Haber: >> What happens if there are multiple ~? > > They are processed in order. > > dpkg --compare-versions handles ~ correctly. And APT? Does it behave differently? (There are differences between the two in the area of epoch handling.) I'm going to add something like the following: - Split the version strings u, v at ~ into components (u_1, ..., u_m), (v_1, ..., v_n). - If m = 0 and m > 0, then we have v < u. - If m = 0 and m = 0, then u = v is the result. - If m > 0 and n = 0, then u < v. - Otherwise, m,n > 0. If u_1 < v_1, then u < v is the result. Conversely, v_1 < u_1 means v < u. But if u = v, recursively compare (u_2, ..., u_m) and (v_2, ..., v_n) using this algorithm. Does this sound reasonable? (There are a few corner cases involving empty components and leading and trailing zeros, but let's ignore them for now, until there is a complete specification.) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#346179: debsecan: doesn't seem to correctly grok ~ in version number
* Florian Weimer: > I'm going to add something like the following: Testing reveals that this not what APT does. I'm inclined to handle ~ versions only if python-apt is installed. Would this be acceptable to you? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
