On Tue, Apr 17, 2007 at 02:22:27PM +0200, Florian Weimer wrote:
It's also a good idea to check against APT's implementation when
playing with strange version numbers (because it's not the same).
Hrm? They used to be significantly different (apt wouldn't cope with
numbers greater than ~0ul or
On Tue, Apr 17, 2007 at 02:22:27PM +0200, Florian Weimer wrote:
FWIW you can experiment quite easily using
dpkg --compare-versions x lt y echo Yes
Interestingly, 4.22.. is considered higher than 4.22.3. I'm not sure
if this is good advice though :-)
It's also a good idea to check
Hi,
I'm currently preparing an NMU for a package which, besides an RC bug,
also has a bug in its last version number. The upstream version is
4.22, but after 4.22-2 the maintainer uploaded 4.22.3.
What do you suggest to get back to a sane version number until there is
a new upstream version
On Tue, Apr 17, 2007 at 10:11:18AM +0200, Frank Küster wrote:
Hi,
I'm currently preparing an NMU for a package which, besides an RC bug,
also has a bug in its last version number. The upstream version is
4.22, but after 4.22-2 the maintainer uploaded 4.22.3.
What do you suggest to get
On Tue, Apr 17, 2007 at 10:11:18AM +0200, Frank Küster wrote:
I'm currently preparing an NMU for a package which, besides an RC bug,
also has a bug in its last version number. The upstream version is
4.22, but after 4.22-2 the maintainer uploaded 4.22.3.
What do you suggest to get back to a
Michael Koch [EMAIL PROTECTED] wrote:
On Tue, Apr 17, 2007 at 10:11:18AM +0200, Frank Küster wrote:
Hi,
I'm currently preparing an NMU for a package which, besides an RC bug,
also has a bug in its last version number. The upstream version is
4.22, but after 4.22-2 the maintainer uploaded
Hamish Moffatt [EMAIL PROTECTED] wrote:
Otherwise, should I use 4.23~real.4.22-3.1 or similar beasts? Or just
go for 4.22.3-0.1 and leave the decision to the maintainer?
FWIW you can experiment quite easily using
dpkg --compare-versions x lt y echo Yes
Interestingly, 4.22.. is
* Hamish Moffatt:
FWIW you can experiment quite easily using
dpkg --compare-versions x lt y echo Yes
Interestingly, 4.22.. is considered higher than 4.22.3. I'm not sure
if this is good advice though :-)
It's also a good idea to check against APT's implementation when
playing with strange
Florian Weimer [EMAIL PROTECTED] wrote:
import apt_pkg
apt_pkg.init()
def compare(a, b):
apt_pkg.VersionCompare(a, b)
# use compare as needed
And what would be as needed, for those who never used apt-python or
even Python at all? Here's my first Python script:
#!/usr/bin/python
import
Hi,
Frank Küster [EMAIL PROTECTED] wrote:
And what would be as needed, for those who never used apt-python or
even Python at all? Here's my first Python script:
When you don't understand, try it interactively from the Python
interpreter:
% python
Python 2.4.4 (#2, Apr 5 2007, 20:11:18)
On Tue, 17 Apr 2007, Frank Küster wrote:
Michael Koch [EMAIL PROTECTED] wrote:
On Tue, Apr 17, 2007 at 10:11:18AM +0200, Frank Küster wrote:
Hi,
I'm currently preparing an NMU for a package which, besides an RC bug,
also has a bug in its last version number. The upstream version is
* Florent Rougon:
This function doesn't return anything (well, actually, it returns the
object None). The correct version is:
def compare(a, b):
return apt_pkg.VersionCompare(a, b)
Yes, indeed, sorry about that. Too much Perl lately. Thanks for
explaining the multi-way compare, too.
On Tue, Apr 17, 2007 at 02:22:27PM +0200, Florian Weimer wrote:
* Hamish Moffatt:
FWIW you can experiment quite easily using
dpkg --compare-versions x lt y echo Yes
Interestingly, 4.22.. is considered higher than 4.22.3. I'm not sure
if this is good advice though :-)
It's also a
Hamish Moffatt [EMAIL PROTECTED] wrote:
What's with having to call apt_pkg.init() manually? That's uncool. It
True, that is very unpythonic. I guess apt_pkg is a very thin and
straight wrapper for the underlying C++ (or is it C?) library.
should be automatic. Simple in a pure Python package
On Tue, 17 Apr 2007, Hamish Moffatt wrote:
On Tue, Apr 17, 2007 at 02:22:27PM +0200, Florian Weimer wrote:
It's also a good idea to check against APT's implementation when
playing with strange version numbers (because it's not the same).
The python-apt package contains a wrapper (not yet
On 4/17/07, Frank Küster [EMAIL PROTECTED] wrote:
I know --compare-versions, but I wasn't patient enough to come to
4.22.. But it 4.22..-3.1 doesn't look too bad to me actually, just
funny.
Other posibilities:
~$ dpkg --compare-versions 4.22.3-1 lt 4.22_-3.1 echo Yes
Yes
~$ dpkg
On Tue, Apr 17, 2007 at 14:53:26 -0300, Margarita Manterola wrote:
On 4/17/07, Frank Küster [EMAIL PROTECTED] wrote:
I know --compare-versions, but I wasn't patient enough to come to
4.22.. But it 4.22..-3.1 doesn't look too bad to me actually, just
funny.
I like 4.22_-3.1, it looks
* Margarita Manterola:
Other posibilities:
~$ dpkg --compare-versions 4.22.3-1 lt 4.22_-3.1 echo Yes
Yes
Keep in mind that dpkg does not check for the validity of version
numbers. _ is in fact forbidden, and I believe there is a check in
dak that enforces that.
(The list of permitted
Margarita Manterola [EMAIL PROTECTED] wrote:
The only thing that worries me a bit is that this prevents any 4.22.x
future upstream version. I guess that an epoch would be need in that
case. (4.22.3 already prevented any upstream version in 4.22.[123]).
Yes, therefore an epoch would be needed
On Tue, Apr 17, 2007 at 09:27:38PM +0200, Florian Weimer wrote:
Keep in mind that dpkg does not check for the validity of version
numbers. _ is in fact forbidden, and I believe there is a check in
dak that enforces that.
(The list of permitted characters in the policy is up to date AFAIK,
Lionel Elie Mamane wrote:
On Tue, Apr 17, 2007 at 09:27:38PM +0200, Florian Weimer wrote:
Keep in mind that dpkg does not check for the validity of version
numbers. _ is in fact forbidden, and I believe there is a check in
dak that enforces that.
(The list of permitted characters in the
On Tue, Apr 17, 2007 at 09:53:58PM +0200, Frank Küster wrote:
Margarita Manterola [EMAIL PROTECTED] wrote:
The only thing that worries me a bit is that this prevents any 4.22.x
future upstream version. I guess that an epoch would be need in that
case. (4.22.3 already prevented any
On Tue, Apr 17, 2007 at 05:02:19PM -0400, Felipe Sateler wrote:
Lionel Elie Mamane wrote:
On Tue, Apr 17, 2007 at 09:27:38PM +0200, Florian Weimer wrote:
(The list of permitted characters in the policy is up to date AFAIK,
except that ~ is missing.)
Not quite, policy says : is allowed in
23 matches
Mail list logo
