Re: APT branch using CMake and debhelper 7 available
On Sat, Nov 21, 2009 at 02:01:19AM +0100, Goswin von Brederlow wrote:
> Julian Andres Klode <jak@debian.org> writes:
>
> > Hi,
> >
> > I just pushed initial CMake support into a new 'cmake' branch[0]. It
> > is not finished yet and misses things like:
>
> Not sure about cmake. Is that something the apt team wants?
I talked to mvo about buildsystems, and proposed 'waf' about 3 months
ago. He agreed that the current buildsystem is not good, but rejected
'waf' due to its Python dependency. He prefered autotools to 'waf', but
also told me that he does not really like it. That's why I went ahead
and implemented something with CMake.
It's just a proposal, but one which can actually be used. We now have
to decide during the next week(s) whether this should be continued or
not.
>
> > * 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).
>
> That is actualy something policy 8.2 requires (MUST directive).
>
> Only issue I see is that if you have multiple libapt-pkgX.Y installed
> they will try to use the same /var/cache/apt/pkgcache.bin, which often
> changes incompatibily between ABI versions. You probably need to add
> a version to the cache files so each X.Y version uses its own.
Either they can read it or not. And AFAIK, apt-pkg will fallback to no
cache (or in-memory) if the cache file is incompatible. This means a few
things will just be a bit slower, but they will continue to work.
I also forgot that libapt-inst should be put in its own package as well,
because otherwise it would not be possible to install two versions of
libapt-pkg at the same time. Thus I propose the following splitup:
* apt
* apt-doc
* apt-transport-https
* libapt-pkg-dev
* libapt-pkg-doc
* libapt-pkg4.8
* libapt-inst1.1
The library packages include their corresponding translations, and apt includes
the tools previously in apt-utils.
>
> > Packages using the acquire functionality would have to depend on libapt-pkg4.8
> > and apt, as the latter would provide the methods.
> >
> > I would like to get your comments about the build system, the proposals,
> > and receive patches for documentation and translation building.
>
> Looks like you are trying to do 2 things at once: Changing the build
> system and splitting the package properly. Always a bad idea to mix 2
> issues as then both need to be accepted together.
I just want to discuss this in parallel, but the buildsystem will have to
be done first. With the new buildsystem, the packaging can be simplified
and it's easier to change the split-up.
--
Julian Andres Klode - Debian Developer, Ubuntu Member
See http://wiki.debian.org/JulianAndresKlode and http://jak-linux.org/.
Reply to: