Re: APT branch using CMake and debhelper 7 available
David Kalnischkies <kalnischkies+debian@gmail.com> writes:
> Hello Julian & Goswin and hi deity@ in general
>
> 2009/11/20 Julian Andres Klode <jak@debian.org>:
>> * Move libapt-pkg and libapt-inst into a libapt-pkg4.8 package.
>> REASON: When they are not shipped in the apt package we can handle
>> ABI breaks more easily without breaking most systems (like requesting
>> removal of python-apt just because it is not recompiled yet).
> Yes, but is it really a good idea to allow a maintainer of a package related
> to package management to be so lazy that two different ABIs are shipped
> in a stable release? The discussion about this seems to be pretty old
> (if not as old as apt itself) and as much as i hate it to destroy unstable
> for a few days or weeks just because the apt team has uploaded an ABI or API
> break it would be even harder for me to see half of the reverse dependencies
> using an obsolete API (or ABI) in testing/stable and therefore using
> obsolete logic to retrieve, install, remove and manage packages.
> I don't think this is something we should support. Therefore we would need to
> enforce a single version in stable versions which we already have now for free.
> (also: maintaining multiple versions - the ones in unstable and the ones in
> stable - would be near to impossible with the current size of the APT Team)
The ABI does break and then apt is in clear violation of Policy 8.2
and for good reason. Nobody is talking about supporting multiple ABIs,
esspecially not in stable. Stable will always only have one source for
apt and therefore one ABI. This also holds true for testing. The
difference with a proper libapt package show up on upgrades,
esspecially partial ones.
As for different versions in stable, testing and unstable you alredady
have to support that. Multiple versions of libapt will only ever be in
unstable and only as long as reverse depends require. So there is
nothing new to support.
> It would also expose us to other problems like the Cache as Goswin mentioned.
> (It would be possible that apt accepts an old format as correct which
> would result in "funny" things... )
That already happens on every upgrade and the cache files are
versioned to detect when the abi changes. If multiple libapt packages
get confused about the cache then so will upgrades. As long as libapt
can work fine without the cache when it is incompatible that is fine.
> I am also considering apt as pseudo-essential, therefore it should work in
> "unpack" (e.g. after dpkg was interrupted by something) which is not given
> with a versionmismatch between apt and libapt...
Which is actualy a reason FOR splitting out libapt. Currently you
unpack a new apt, somethng goes wrong and then aptitude won't work
anymore. Or synaptic. Or any other frontend. With the split package
the old libapt remains while the new libapt is unpackaged so frontends
that haven't yet unpacked remain functional.
And I agree that libapt should work while unconfigured. As there is
nothing to configure that works out of the box anyway.
> I think it would be better to stabilize the API more & more, e.g.
> with the help of fvisibility ... especially as we don't break the API
> so often and an ABI break-fix is just a simple binNMU away...
That changes nothing. Even if it is just once a release all the above
points remain valid. And if the ABI/API remains stable all your fears
are pointless.
> Packages we should really build from the source would be
> (at least in my eyes)
> * apt-dbg (obsolete if the automatic debug-package build goal is reached)
> * apt-common to collect locals & translations of manpages in an arch-indep
> package instead of shipping them for every arch independently.
> (lintian doesn't complain about it now, but if we get a few more manpage
> translations it should start soonish to do it and it would support nicely
> a few hacks for embed devices and could come in handy if tdebs steps out
> of the dark draft state - so more or less a win-win situation)
> The good part is that I already spent a few minutes this week to do this
> and i intended to propose that to Michael for the next upload - it is just
> a question of how fast we complete the real tasks for the next version ...
>
>> I would like to get your comments about the build system, the proposals,
>> and receive patches for documentation and translation building.
> ... - no offense intended - but it looks to me that cmake will fix a problem
> which doesn't really exist or isn't as major as other problems we should
> tackle (at first), e.g. all the funny resolver stuff needed for multi-arch
> (the download of the Packages files is trivial and a [unfinished] patch
> from Goswin already exists). As some already noticed the acquire system also
The part that is unfinished is CD handling. I don't have an amd64
and i386 DVD set to test this. So if anyone has the CDs/DVDs already
and wants to help please do. Saves me the trouble of burning 2
otherwise useless DVDs.
> need some work, not so much on the speed part (come one, i can't even imagine
> a situation in which 20.000 items are in the query, so why discussion it as
> it would be a major problem) but on the extensibility side:
> Quite a few clients have metadata which should be in sync with the Packages
> files and should therefore be updated also in an "apt-get update":
> debtags comes to my mind, all the fancy stuff Ubuntu Software Center
> wants to show is another one and even the multi-arch thing above and
> things like the ability to download multiple Translation-files would benefit
> from it, while it is not strictly required for the last two things.
> (bonus: if it is done right all these files could get checksum, pdiffs
> and/or future extensions like zsync basically for free)
There is one benefit for the split libapt pakage that hasn't been
mentioned yet: Developement and testing.
Currently when you change the apt ABI/API you can not install the new
apt on your system without removing or recompiling all rdepends. With
a libapt package I could install a new libapt and apt while aptitude
remains functional with the old one. That way, if the new libapt is
broken, I can still use aptitude to remove it again.
> Best regards / Mit freundlichen Grüßen,
>
> David "DonKult" Kalnischkies
>
>
> [0] http://wiki.debian.org/Teams/Dpkg/RoadMap
>
>
> --
> To UNSUBSCRIBE, email to deity-REQUEST@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
MfG
Goswin
Reply to: