Re: Library packages and their use
wyo@users.sourceforge.net (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 dmaze@debian.org http://people.debian.org/~dmaze/
"Theoretical politics is interesting. Politicking should be illegal."
-- Abra Mitchell
Reply to: