Johannes Schauer <j.scha...@email.de> (2014-07-28): > Quoting Cyril Brulebois (2014-07-28 16:40:49) > > > diff -Nru apt-0.9.7.9+deb7u2/debian/libapt-pkg4.12.symbols > > > apt-0.9.7.9+deb7u3/debian/libapt-pkg4.12.symbols > > > --- apt-0.9.7.9+deb7u2/debian/libapt-pkg4.12.symbols 2013-03-01 > > > 10:51:21.000000000 +0000 > > > +++ apt-0.9.7.9+deb7u3/debian/libapt-pkg4.12.symbols 2014-07-28 > > > 11:32:23.000000000 +0000 > > > @@ -369,6 +369,7 @@ > > > (c++)"debListParser::VersionHash()@Base" 0.8.0 > > > (c++)"debListParser::Architecture()@Base" 0.8.0 > > > (c++)"debListParser::ParseDepends(char const*, char const*, > > > std::basic_string<char, std::char_traits<char>, std::allocator<char> >&, > > > std::basic_string<char, std::char_traits<char>, std::allocator<char> >&, > > > unsigned int&, bool const&, bool const&)@Base" 0.8.0 > > > + (c++)"debListParser::ParseDepends(char const*, char const*, > > > std::basic_string<char, std::char_traits<char>, std::allocator<char> >&, > > > std::basic_string<char, std::char_traits<char>, std::allocator<char> >&, > > > unsigned int&, bool const&, bool const&, bool const&)@Base" 0.9.7.9+deb7u2 > > > > This is wrong. > > Why? > > And how would it be done "right"?
Pretty sure 0.9.7.9+deb7u2 doesn't ship the symbol you pretend it does… (Ansgar told you where to look, by the way.) > > > diff -Nru python-apt-0.8.8.2/debian/control > > > python-apt-0.8.8.2+deb7u1/debian/control > > > --- python-apt-0.8.8.2/debian/control 2013-03-13 22:25:59.000000000 +0000 > > > +++ python-apt-0.8.8.2+deb7u1/debian/control 2014-07-28 > > > 11:46:59.000000000 +0000 > > > @@ -10,7 +10,7 @@ > > > apt-utils, > > > debhelper (>= 7.3.5), > > > fakeroot, > > > - libapt-pkg-dev (>= 0.8.11), > > > + libapt-pkg-dev (= 0.9.7.9+deb7u3), > > > > I'm pretty sure this a bad idea. > > > > This happened not so long ago: > > [12 Jun 2014] DSA-2958 apt - security update > > > > Next apt update would mean python-apt is no longer buildable in stable. > > This is correct. I am not aware of a correct way to express this dependency. Well, as usual, >= foo together with << bar? > > I know nothing about python bindings but anyway, it looks like you're > > not updating doc strings. > > I can easily update all the necessary doc strings. But it seems that more > fundamental questions should be solved first. Right. > > More importantly, what's the impact in packages using those functions? Were > > packages identified, their code reviewed, and their features tested? > > I might lack the necessary understanding but given the changes expressed in > the > patches I cannot imagine in what way packages depending on apt or python-apt > would start failing or having any different functionality besides not failing > when faced with the new syntax. > > For python-apt, none of the exposed python functions gained new arguments and > thus no code should break. The only difference now is, that it will be able to > understand the new syntax. > > For libapt-pkg4.12, existing code will be calling ParseDepends in a way which > sets ParseRestrictionsList to false and thus should not experience any > functionality change at all. To be able to understand the new syntax as well, > they'd have to explicitly call ParseDepends with ParseRestrictionsList=true. > But this is no change in functionality from the status quo. > > If you want us to do any additional tests, I'll be glad to carry them out. I read this as “no tests have been performed”. Not quite what I'd expect for things as critical as a new apt in stable… Mraw, KiBi.
signature.asc
Description: Digital signature
