[EMAIL PROTECTED] (Otto Wyss) writes:
The discussion about the libc6-dev package and its headers let me to the
impression that the Debian package structure isn't optimal for
libraries. If anyone wants to build his own version of a package (i.e.
libwxgtk2.4) he has to get all the dependent underlying dev packages as
well. This is a long line of dependencies which mostly aren't wished and
shouldn't be necessary.
Why is this a problem? I don't really understand, for example, why
you want to recompile libraries, or what the problem is with needing
to have -dev packages installed to get header files for libraries.
There are 3 kinds of dissimilar user groups of a package:
1. Users just using a library linked to other packages
(...who don't want the header files, static libraries, or .so links;
they're just users.)
2. Developers building packages which depends on a library package
(...who need the header files, etc.)
3. Developers building his own version of this library package
I don't understand this category in particular. Do you mean
maintainer? Or do you really want to install home-built versions of
libraries? Supporting home-built versions of system things (not just
libraries, but also things like MTAs) is something Debian has
traditionally been bad at; if I was going to optimize for this, I'd
probably use a BSD distribution over anything Linux-based.
Currently group 1 just uses the normal packages while group 2 + 3 have
both to use the dev packages. Especially for group 2 this isn't a good
solution leading to a long line of unnecessary dependencies.
Again, what makes them unnecessary? If myapp.c includes foo/foo.h,
and foo/foo.h includes bar/bar.h, then you can't compile myapp.c
without having bar/bar.h around, period. Which means that, in the
Debian world, you need to have libbar-dev installed, even if myapp.c
doesn't include anything out of bar.h directly.
Solution 1: Splitting the 2 packages into 3. Not very attractive, it
will more confuse than improve the situation. Maybe the dbg packages
could take over the role of the 3. group.
...what is the proposed split here? All of your proposals are kind of
hand-wavy, and I really don't understand what you're getting at.
Solution 2: Packages are changed that group 1 + 2 can use the normal
packages and only group 3 uses the dev. That means the normal library
packages contain enough so that other packages depending on this can be
build.
That sounds like a proposal to get rid of -dev packages entirely. Is
that what you're actually proposing?
I'm not sure if any of the above solutions will improve the situation
but we should all try to remove dependencies wherever possible.
Dependencies are bad? Yeah, there are lots of ways to get around
them (static linking and the like) but they come with lots of costs
(binary bloat, need to rebuild every package when libc changes).
--
David Maze [EMAIL PROTECTED] http://people.debian.org/~dmaze/
Theoretical politics is interesting. Politicking should be illegal.
-- Abra Mitchell
