[Aptitude-devel] apt, ABI breakages, etc -- was: Bug#764506: Processed: severity of 764506 is normal

Wed Dec 3 21:50:42 UTC 2014

On Thu, Nov 27, 2014 at 07:42:45PM +0000, Manuel A. Fernandez Montecelo wrote:
> 2014-11-27 14:08 David Kalnischkies:
> >On Tue, Nov 25, 2014 at 10:42:10AM +0100, Axel Beckert wrote:
> >>Anyway: Reason why I consider this not even important is that nobody
> >>so far checked if rebuilding aptitude against apt from experimental
> >>would already solve the issue -- which IMHO is not that unlikely. (I
> >>though could imagine that it may FTBFS on that occassion.)
> >
> >JFTR: we did quite a few times before being denied the abibreak for
> >jessie, so I am pretty sure a rebuild against the new abi is all what is
> >needed (modulo any breakage we introduced since then, but well) to fix
> >this, but this is something we will continue to work on after jessie.
> 
> Would it be useful to use different package names to avoid these
> issues?

Well, that we change name is actually the problem… Back in the "good old
days" src:apt didn't build a libapt-pkg?.?? package, but the apt package
provided such a package name. This made transitions a pain in the a**,
but it also meant that it was impossible to have an "old" aptitude talk
via an "old" library to the "new" acquire methods.

In comparison abi transitions happen "often" (they are still painful, so
we avoid them still as much as possible) while it is less likely that
library and methods disagree in their interactions thanks to the textual
interface they have. In fact, they don't do it now either. The new
methods just assumed that their caller does some "extra" work before and
after calling them, which isn't actually happening if the caller is old.
Well, the fix was simple: Don't assume that.

It "just" slipped through as partial upgrades aren't tested that often
as it tends to be hard to test it. So, the solution is to have more
(automatic) tests…

On that note: Any plans for autopkgtests for aptitude?
(Not that this would cover this case, but it could help.)

> >That said, there will be some work in the form of various deprecated
> >methods and members to make use of all the good stuff (and get right of
> >the bad things) so the compiler will be quite chatty, but it is
> >hopefully clear what to do about them and in any case: It would be
> >a "stretch" to call this an important todo-list item at the moment…
> 
> Is it possible to fix this in advance (before changes in apt happen)
> by changing aptitude (and other deps) to stop using some
> methods/whatever that will be deprecated, or cannot be done in advance
> because the "good-stuff" is not developed/ready yet, and will be done
> simultaneously with the deprecation?

Depends. The version which just entered unstable (and hopefully soon
jessie) includes an "abi correction" which you can (maybe even should)
fix instantly for any version as a better way exists since ever:

pkgCache::Package has a Section member – aka: PkgIterator has
a Section() method – which is in general totally bogus as different
versions can be in different sections. Thankfully, Version always had
a section member as well, so the reasonable thing to do is to check any
code (and apt actually had a few parts) dealing with sections, that it
uses the section from the version, not from the package.

A quick grep over aptitude shows a few places which use pkg.Section().
I got this fix approved for jessie, so I would predict you could, too,
as this can have "strange" effects for packages changing sections
(apt would incorrectly manual-bit some e.g., I guess aptitude would
mostly show them in the wrong overview, but that is a very wild guess,
if nobody beats me to it I might look closer at it at the weekend and/or
report a bug about it).

On the other hand, the changes to the acquire system (which triggered
these bugreports) also include new ways of dealing with hashsums so that
in the best case we can add SHA3 or drop MD5 "transparently" now.
You can't stop using the old way without requiring a newer libapt-pkg
version in that case, which might or might not be a problem for you
(e.g. backports).

The version in experimental is kinda a preview for all this and will
went live sometime after jessie release. That is usually a two-fold
process: Some day we will upload a new src:apt to unstable contain the
new stuff and the release team will shedule binNMUs for all our reverse
dependencies. Assuming everything works out well the transition is done
from our point of view. The "problem" for you now is that the previously
(hopefully) warning free build of aptitude will have a bunch of warnings
talking about aptitude using deprecated stuff. As the good boy you are,
you go and silence all these warnings while I will be happily working on
producing the next batch of warnings for you with the next release. ;)
(And at some point, we might even drop the deprecated stuff, but at that
point hopefully nobody uses it anymore (for eons))

> >So feel free to bug me (or deity@) about this after jessie, but not
> >a minute earlier. ;) (assuming apt is actually part of the jessie
> >release… lets say it this way: I have some mixed signals here…)
> 
> I don't know if I am getting this right... but do you really think
> that it's a possibility that Jessie ships without apt!?!

Ill-fated joke refering to a (at this time) future (and now confined to
a parallel universe) joking reply to #769308 as nobody seems to have the
time to work on all this stuff in a very timely fashion. While its fun to
think about how that would simplify everything, its a bit unlikely to
happen in the immediate future. So now worries, we aren't going back to
dselect anytime soon (not that I would have experience with it. The
closest I came to dselect is that I meet a person at debconf who said
that he is still using it at times… close enough for me – no offense).

(mhh, that was a longer mail than I planed/expected … "If I had more
time, I would have written a shorter letter." … well, no, probably not)

Best regards

David "Babel fish" Kalnischkies
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.alioth.debian.org/pipermail/aptitude-devel/attachments/20141203/70063521/attachment.sig>