[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: naming and relationships of development packages

On Sun, Oct 08, 2006 at 11:14:51PM +0200, Székelyi Szabolcs wrote:
> Hi,
> Ming Hua wrote:
> > On Fri, Oct 06, 2006 at 01:10:32AM +0200, Székelyi Szabolcs wrote:
> >> James Westby wrote:
> >>
> >>>   * Do you need Replaces: libvrb-dev as well?
> >> I have seen similar (ie. development) packages with and others without
> >> this. Do I?
> > 
> > If you want to support upgrading for users who use you previous
> > unofficial package, and libvrb0-dev ships the same files as libvrb-dev,
> > then yes, you need Replaces: (and probably also Conflicts:) libvrb-dev.
> There is no libvrb-dev package. It is a virtual package to ensure that
> only one development version is installed at a time (Provides + Conflicts).

I see.  Didn't notice libvrb0-dev Provides libvrb-dev before, sorry.

> > I know the naming of -dev packages is a
> > very controversial topic, so I want to hear your (and other people's)
> > opinion.
> The soversion is usually added to the -dev package name to be able to
> support multiple versions of a library off-line, which means all
> versions can be found in the archive, but only one can be installed on
> the user's machine.

I think what I really wanted to ask is what would be a good reason to
have multiple versions of a library avaiable in the archive.  The
package I maintain, scim, changes its SONAME once in a while, but keeps
API compatible all the way, so I only keep one -dev package, without

My impression is that if you make both libfoo0-dev and libfoo1-dev
provide and conflict libfoo-dev, you are implying that porting a package
building against libfoo0 to building against libfoo1 should be zero or
minimal effort.  If that's the case, isn't keeping only one -dev package
a better choice, if just to encourage other packages to migrate to the
newer version of the library?

> The question is, which mechanism should be used to
> accomplish this? Do we need Replaces:? I think Provides and Conflicts is
> enough.

The Debian Library Packaging Guide (written by Junichi Uekawa, mentioned
by a lot of DDs, but AFAIK is still an unofficial guide) seems to agree
with you:



Reply to: