Boris Kolpackov <[EMAIL PROTECTED]> wrote: >> There has to be a separate -dev package for each source package, >> though it's okay if libxerces-c-dev belongs to the most recent one and >> older ones, if any, have a numbered libxerces-cnn-dev package. This >> is how the Berkeley DB packages are managed. > > Hm, I guess it can be done either way. For example, there are libicu34, > libicu36, and libicu38, however, only one libicu-dev. You schema has > an advantage of allowing both, say, libxerces-2-dev and libxerces-3-dev > to be in the repository with the user being able to select which to > install. I would, however, suggest that we use the major release number > in both -dev packages so that they correspond to libxerces-c packages > (that is libxerces-2 and libxerces-2-dev, libxerces-3 and libxerces-3-dev).
I'm planning on having libxerces-c-dev "provide" libcxerces-c3-dev. That means people can select libxerces-c3-dev explicitly if they choose, but the name "libxerces-c-dev" will always belong to the latest version. This is the same scheme used by Berkeley DB, and I think it works nicely because it means you have to take specific action to not depend on the latest version. ICU is another good example. Actually, I'm also the debian maintainer for ICU (not coincidentally -- it's because it's a dependency of xerces that I took over the package when its previous maintainer retired). The libicu34, libicu36, and libicu38 packages all came from different versions of the icu source package. There's no way in lenny (or sid/unstable) to install libicu34 or libicu36 anymore since the icu source package no longer supplies them. By having the -dev package be libicu-dev instead of libicu38-dev, the next source-compatible ICU release can be a binary only transition. Otherwise, people have to change their source packages to change the build dependencies from libicu34-dev to libicu36-dev to libicu38-dev. In fact, I used to have the soname version in the -dev package, but over time, I realized that doing so makes library transitions harder. For people who need to specify an exact version, they can use versioned dependencies. --Jay --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
