Bug#383615: split out libaprutil1-dev sqlite, pgsql, ldap dependencies
On 8/21/06, Tollef Fog Heen <firstname.lastname@example.org> wrote:
* "gmu 2k6"
| it's not about disk space, it's about installing as few packages as
| possible to have a clean selection with a minimum of update
| if Debian is "the universal OS" then it should allow clean installs
| without falling back to apt-build.
This is a _development package_, not something which drags in lots of
random on a nondeveloper's system. And even if it was, it's just a
few libraries and nothing complicated. Compared with the extra
overhead of maintaining a split libapr-dev, it's too much so we won't
| one of the major reasons I'm using Debian out of the binary
| distros is that it allows me to install a minimal system and let
| me decide which packages I want, most of the time. although
| we are much better than RPM based distros which don't seem
| to have a "Suggest" field some packages are not done right
| regarding the features one can to enable/disable during
You can't disable the fact that libapr is linked with sqlite,
postgres, ldap and more at runtime.
as I proposed you could build additional packages which
enable the db-backends.
| just take the libwxgtk packages which requires esound, this
| is only so because the packager did not split the package
| in -base, -sound, etc. the point here is that wxWindows is
| most likely used for the GUI abstraction and not for sound.
| insert `apt-cache depends xchm` here.
xchm doesn't depend on and sound on my system at least.
$ apt-cache depends xchm
$ apt-cache depends libwxgtk2.6-0
| I'm using libaprutil1-dev to build Subversion >=1.3.x/1.4(rc)
| and the dependency I saw with it is similar to installing some
| font or graphics libs which require the whole Xorg baselibs
| chain. I build Subversion, because Apache 2.2 is not in etch/sid
| yet and so it is built against APR 1.0.x right now my own
| -DLARGEFILE aka APR 1.2.x Subversion. btw, this does not
| mean I'm using mod_dav_svn, svnserve is all I need as of know.
You're aware that subversion 1.4rc is in experimental, right?
no, I wasn't but maybe I should start pinning some experimental
I'm closing this bug since we have no interest in the extra overhead;
you don't have to be sorry, we did at least discuss my issue with it and
now that I see your point I know that it won't change and have to find
a different way to cope with it.