help-libidn
[Top][All Lists]
Advanced

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

Bug#863030: Do not encode soversion in source and dev package name


From: Simon Josefsson
Subject: Bug#863030: Do not encode soversion in source and dev package name
Date: Mon, 17 Jul 2017 12:00:19 +0200

mån 2017-07-17 klockan 11:56 +0200 skrev Michael Biebl:
> Am 17.07.2017 um 08:48 schrieb Simon Josefsson:
> > Hi Michael.  I don't agree with renaming the package name.  The
> > debian
> > policy manual says in section 8.1 [1] that:
> > 
> >        The run-time shared library must be placed in a package
> > whose
> >        name changes whenever the SONAME of the shared
> >        library changes.  This allows several versions of the shared
> >        library to be installed at the same time, allowing
> > installation
> >        of the new version of the shared library without immediately
> >        breaking binaries that depend on the old version.  Normally,
> >        the run-time shared library and its SONAME symlink should be
> >        placed in a package named librarynamesoversion, where
> > soversion
> >        is the version number in the SONAME of the shared library.
> >        Alternatively, if it would be confusing to directly append
> >        soversion to libraryname (if, for example, libraryname
> > itself
> >        ends in a number), you should use libraryname-soversion
> > instead.
> > 
> > This is what I believe we are doing.  Can you explain more in
> > detail
> > what is wrong?  From my reading, we are doing what we should do,
> > and
> > what you suggest would not be consistent with the above.
> > 
> 
> I'm talking about the the dev and source package, not the library
> package, i.e.
> using a soversion in
> Package: libidn2-0
> is fine, but it's wrong for
> 
> Source: libidn2-0
> Package: libidn2-0-dev
> 
> 
> Use
> Source: libidn2
> Package: libidn2-dev
> instead

Sorry, I misunderstood.  Yes, I agree.  It could be argued that we
could keep libidn2-0-dev, if we want to allow having multiple versions
around.  But this is not likely.

I'll let the package move into testing and then make the change.

Thanks,
/Simon

Attachment: signature.asc
Description: This is a digitally signed message part


reply via email to

[Prev in Thread] Current Thread [Next in Thread]