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

Thu Dec 4 21:31:18 UTC 2014

2014-12-03 21:50 David Kalnischkies:
>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.

Hmm, I see.

I was thinking also perhaps to provide different source packages for
src:apt (so they could be co-installed), but apart from being more
work it's probably dangerous if both are reading and writing the same
sets of files.  So most probably not worth it.

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

They would certainly be useful.

Since my permissions to commit were retired almost a year ago, and I
asked the CTTE for a resolution on the matter and nothing was done
(understandably, the ctte was very busy lately due to other matters),
I am not very keen on starting any effort that has chances of being
ignored or overriden... all that I can say is that I do not have plans
to do this at the moment.

>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 a quick grep, there are a few calls to Section(), and I think that
at least some of them to the pkgCache::Package one.  So it could
affect the search, sorting, grouping, and so on.

If there are warnings about deprecations (as you say below), and
better, if there is some documentation with changes with clear
instructions about the alternatives (as you did in the paragraphs
above), it will probably be fixed relatively quick in the rev-deps.
At least the ones in Debian, like aptitude.

>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).

There have been no backports in the last few years, AFAIK, so this is
probably not a big concern.

>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))

Sounds good.

>> 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).

Heh... Coincidentially, I felt a bit nostalgic and fired it up the
other day... didn't go far enough as to actually try to
install/upgrade/remove packages with it, though.

Cheers.
--
Manuel A. Fernandez Montecelo <manuel.montezelo at gmail.com>