Re: APT branch using CMake and debhelper 7 available
Hello Julian & Goswin and hi deity@ in general
2009/11/20 Julian Andres Klode <jak@debian.org>:
> * Merge apt-utils into apt (+400kB)
> REASON: libdb4.7 is required, and they otherwise have the same
> dependencies; they also have the same priority (important);
> and 400kB are not very much.
The dpkg team at least plans to "Merge back apt-exttracttemplates" [0].
(but no message to deity@ about this or the other plans so far)
As i think the package is only important because of this application and
the others are only useful for repositorybuilders i would leave the package
as is for now and after the back merge drastically downgrade the priority.
(btw as a nitpicker i need to say:
apt already builds itself against libdb4.8 ;) )
> * 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)
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... )
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...
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...
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
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)
Best regards / Mit freundlichen Grüßen,
David "DonKult" Kalnischkies
[0] http://wiki.debian.org/Teams/Dpkg/RoadMap
Reply to: