Merge lp:~jelmer/launchpad/noversion into lp:launchpad
| Status: | Merged |
|---|---|
| Merged at revision: | 11282 |
| Proposed branch: | lp:~jelmer/launchpad/noversion |
| Merge into: | lp:launchpad |
| Diff against target: |
583 lines (+46/-405) 3 files modified
lib/lp/archivepublisher/debversion.py (+21/-129) lib/lp/archivepublisher/tests/test_debversion.py (+23/-263) lib/lp/soyuz/scripts/buildd.py (+2/-13) |
| To merge this branch: | bzr merge lp:~jelmer/launchpad/noversion |
| Related bugs: |
| Reviewer | Review Type | Date Requested | Status |
|---|---|---|---|
| Abel Deuring (community) | 2010-03-10 | Needs Information on 2010-03-12 | |
|
Review via email:
|
|||
Description of the Change
Remove duplicate implementation of Debian version parsing but instead rely on python-debian's parsing code (also used in dak and bzr-builddeb, so we already have it present).
This also removes a couple of other utility functions that weren't used in Launchpad.
| Jelmer Vernooij (jelmer) wrote : | # |
This test already existed, I've just changed it to use assertEquals.
Older versions of Launchpad also had this behaviour and it's required by Debian policy. It looks like older versions of python-debian considered 1.0 < 1.0-0.
I'll see if we can include python-debian in Launchpad or provide backports of python-debian so we're sure we have a working version.
| Jelmer Vernooij (jelmer) wrote : | # |
> I'll see if we can include python-debian in Launchpad or provide backports of
> python-debian so we're sure we have a working version.
(python-debian is available because it is a dependency of bzr-builddeb, launchpad doesn't have an explicit dependency on it).
| Abel Deuring (adeuring) wrote : | # |
On 12.03.2010 11:43, Jelmer Vernooij wrote:
> This test already existed, I've just changed it to use assertEquals.
Right, but you changed the implemention of the tested class, so this is
a genuine test failure ;)
>
> Older versions of Launchpad also had this behaviour and it's required by Debian policy. It looks like older versions of python-debian considered 1.0 < 1.0-0.
OK. But the is question why this "relaxed equality comparison" was
introduced and even tested, and if we can remove it again.
>
> I'll see if we can include python-debian in Launchpad or provide backports of python-debian so we're sure we have a working version.
| Jelmer Vernooij (jelmer) wrote : | # |
> On 12.03.2010 11:43, Jelmer Vernooij wrote:
> > This test already existed, I've just changed it to use assertEquals.
> Right, but you changed the implemention of the tested class, so this is
> a genuine test failure ;)
Yep - thanks, I'm not sure how I missed that.
> > Older versions of Launchpad also had this behaviour and it's required by
> Debian policy. It looks like older versions of python-debian considered 1.0 <
> 1.0-0.
> OK. But the is question why this "relaxed equality comparison" was
> introduced and even tested, and if we can remove it again.
It was inherited from sourcerer and this is mainly a theoretical situation. "0" should never be used as the debian revision and it would only ever apply anyway if somebody changed a native package to no longer be native while keeping the upstream version the same *and* using 0 for the debian revision.
Still, it would be nice to get right just in case somebody happens to ever do something like that. It would be confusing if dpkg and launchpad behaved differently. I've filed a bug against apt in debian about this and noted it in the source code.
| Abel Deuring (adeuring) wrote : | # |
On 12.03.2010 19:52, Jelmer Vernooij wrote:
>> On 12.03.2010 11:43, Jelmer Vernooij wrote:
>>> This test already existed, I've just changed it to use assertEquals.
>> Right, but you changed the implemention of the tested class, so this is
>> a genuine test failure ;)
> Yep - thanks, I'm not sure how I missed that.
>
>>> Older versions of Launchpad also had this behaviour and it's required by
>> Debian policy. It looks like older versions of python-debian considered 1.0 <
>> 1.0-0.
>> OK. But the is question why this "relaxed equality comparison" was
>> introduced and even tested, and if we can remove it again.
> It was inherited from sourcerer and this is mainly a theoretical situation. "0" should never be used as the debian revision and it would only ever apply anyway if somebody changed a native package to no longer be native while keeping the upstream version the same *and* using 0 for the debian revision.
>
> Still, it would be nice to get right just in case somebody happens to ever do something like that. It would be confusing if dpkg and launchpad behaved differently. I've filed a bug against apt in debian about this and noted it in the source code.
OK, so, what shall we do with this test failure? Adjust the test or
change the __cmp__ method of the tested class?
I have no clue if the new comparison may have any side effects on other
code -- I simply don't understand enough about Soyuz and the fine
details about Debian packages in general.
Can/should we simply ensure that version strings without the "-0" are
rejected? That would make the test obsolete. (Do we already have
packages where this "-0" is missing?)
If we keep the new comparison: Can it happen that we have two package
versions 1.0 and 1.0-0? How would Launchpad deal with these packages?
And how would apt, dpkg and other package management tools deal with
these versions?
Abel
| Jelmer Vernooij (jelmer) wrote : | # |
Hi Abel,
On Mon, 2010-03-15 at 08:45 +0000, Abel Deuring wrote:
> On 12.03.2010 19:52, Jelmer Vernooij wrote:
> >> On 12.03.2010 11:43, Jelmer Vernooij wrote:
> >>> This test already existed, I've just changed it to use assertEquals.
> >> Right, but you changed the implemention of the tested class, so this is
> >> a genuine test failure ;)
> > Yep - thanks, I'm not sure how I missed that.
> >
> >>> Older versions of Launchpad also had this behaviour and it's required by
> >> Debian policy. It looks like older versions of python-debian considered 1.0 <
> >> 1.0-0.
> >> OK. But the is question why this "relaxed equality comparison" was
> >> introduced and even tested, and if we can remove it again.
> > It was inherited from sourcerer and this is mainly a theoretical situation. "0" should never be used as the debian revision and it would only ever apply anyway if somebody changed a native package to no longer be native while keeping the upstream version the same *and* using 0 for the debian revision.
> >
> > Still, it would be nice to get right just in case somebody happens to ever do something like that. It would be confusing if dpkg and launchpad behaved differently. I've filed a bug against apt in debian about this and noted it in the source code.
>
> OK, so, what shall we do with this test failure? Adjust the test or
> change the __cmp__ method of the tested class?
The __cmp__ not working properly is actually a bug deep down in apt, so
I've filed a bug against it in Debian and disabled the test for now.
> I have no clue if the new comparison may have any side effects on other
> code -- I simply don't understand enough about Soyuz and the fine
> details about Debian packages in general.
I'm quite sure this shouldn't have any side effects.
> Can/should we simply ensure that version strings without the "-0" are
> rejected? That would make the test obsolete. (Do we already have
> packages where this "-0" is missing?)
It's the other way around - -0 would be missing generally, I don't think
there is anybody using -0 at the moment. I guess we could refuse
packages with a "0" Debian revisions for now, I'll ask if that'd be
acceptable.
> If we keep the new comparison: Can it happen that we have two package
> versions 1.0 and 1.0-0? How would Launchpad deal with these packages?
> And how would apt, dpkg and other package management tools deal with
> these versions?
No, we can't have both a package without and with -0 because they would
be deemed the same package, would need to have the same MD5sum (but
can't because their debian/changelog file would differ).
Cheers,
Jelmer
| Abel Deuring (adeuring) wrote : | # |
Hi Jelmer,
We are now really reaching a topic where I don't any real knowledge at
all, so I'm swtiching into "paranoia mode". If you think this is
inappropriate, you might consider to ask somebody else for a review ;)
On 17.03.2010 11:00, Jelmer Vernooij wrote:
> Hi Abel,
>
> On Mon, 2010-03-15 at 08:45 +0000, Abel Deuring wrote:
>> On 12.03.2010 19:52, Jelmer Vernooij wrote:
>>>> On 12.03.2010 11:43, Jelmer Vernooij wrote:
>>>>> This test already existed, I've just changed it to use assertEquals.
>>>> Right, but you changed the implemention of the tested class, so this is
>>>> a genuine test failure ;)
>>> Yep - thanks, I'm not sure how I missed that.
>>>
>>>>> Older versions of Launchpad also had this behaviour and it's required by
>>>> Debian policy. It looks like older versions of python-debian considered 1.0 <
>>>> 1.0-0.
>>>> OK. But the is question why this "relaxed equality comparison" was
>>>> introduced and even tested, and if we can remove it again.
>>> It was inherited from sourcerer and this is mainly a theoretical situation. "0" should never be used as the debian revision and it would only ever apply anyway if somebody changed a native package to no longer be native while keeping the upstream version the same *and* using 0 for the debian revision.
>>>
>>> Still, it would be nice to get right just in case somebody happens to ever do something like that. It would be confusing if dpkg and launchpad behaved differently. I've filed a bug against apt in debian about this and noted it in the source code.
>> OK, so, what shall we do with this test failure? Adjust the test or
>> change the __cmp__ method of the tested class?
> The __cmp__ not working properly is actually a bug deep down in apt, so
> I've filed a bug against it in Debian and disabled the test for now.
OK, this sound good. But for now we have to deal with this somewhat odd
comparison in apt. I assume that apt in Ubuntu is also affected -- but
even if it not, we must deal with upstream having this bug.
>
>> I have no clue if the new comparison may have any side effects on other
>> code -- I simply don't understand enough about Soyuz and the fine
>> details about Debian packages in general.
> I'm quite sure this shouldn't have any side effects.
This sounds good, but let's be sure. Can we query our database for
possible bad version strings, i.e., strings that end with "-0"? If we
don't have any, that's good, but we should also ensure that such version
strings cannot be created in the future. Perhaps I am putting too much
"meaning" into the version string, but I think it is a kind of unique
identifier for a package version, so we should be really sure that we
don't create a mess by allowing two version strings in Launchpad meaning
"locally" that they are different versions, while they are considered
identical elsewhere.
And we should ensure that we can't create version strings in LP ending
with '-0' in the future.
>
>> Can/should we simply ensure that version strings without the "-0" are
>> rejected? That would make the test obsolete. (Do we already have
>> packages where this "-0" is missing?)
> It's the other way around - -0 would be missing generally, I don't th...
| Jelmer Vernooij (jelmer) wrote : | # |
Hi Abel,
> We are now really reaching a topic where I don't any real knowledge at
> all, so I'm swtiching into "paranoia mode". If you think this is
> inappropriate, you might consider to ask somebody else for a review ;)
I've discussed the issue with Julian and we've decided to put this branch on hold. There is a fix for the bug in apt available which should land in Lucid. Once Launchpad migrates to Lucid, we'll just get that bug fix for free and can land this branch then; since this branch is mostly removing duplicate code there is no hurry.

Hi Jelmer,
overall, your changes look good. But I get a test failure when I run ./bin/test -t test_debversion:
Failure in test testNullRevisio nIsZero (lp.archivepubl isher.tests. test_debversion .VersionTests) python2. 5/unittest. py", line 260, in run abel/canonical/ lp-branches/ review- jelmer/ lib/lp/ archivepublishe r/tests/ test_debversion .py", line 132, in testNullRevisio nIsZero assertEquals( Version( "1.0"), Version("1.0-0")) python2. 5/unittest. py", line 334, in failUnlessEqual
Traceback (most recent call last):
File "/usr/lib/
testMethod()
File "/home/
self.
File "/usr/lib/
(msg or '%r != %r' % (first, second))
AssertionError: Version('1.0') != Version('1.0-0')
Are you sure that the new, more strict, comparison does not have any bad side effects?
(And if
Version('1.0') != Version('1.0-0')
works in Launchpad, I think you can remove this test.)