Re: conflicts and replace
On Thu, Sep 08, 2011 at 08:54:21AM +0200, Ludovic Brenta wrote:
> I propose the following small change to the Debian Policy for Ada:
> --- debian-ada-policy.texi
> +++ debian-ada-policy.texi
> @@ -1119,7 +1118,14 @@ @subsection Avoiding the indirect FTBFS
> it is necessary that the package @code{libconfig<aliversion>-dev} have
> @samp{Conflicts} and @samp{Replaces} clauses in its
> @file{debian/control} that list all previous versions of the
> -@code{-dev} package.
> +@code{-dev} package. The @samp[Conflicts}/@samp{Replaces}
> +relationship can be indirect and implicit through @code{gnat-X.Y}. If
> +@code{libconfig1-dev} depends on @code{gnat-4.1} and
> +@code{libconfig2-dev} depends on @code{gnat-4.3}, an explicit
> +@samp{Conflicts:} is unnecessary because @code{gnat-4.1} and
> +@code{gnat-4.3} already conflict with each other, preventing
> +coexistence of @code{libconfig1-dev} and @code{libconfig2-dev} as
> +intended.
After reading this paragraph, I understand that libconfig2-dev
Conflicts:
Replaces: libconfig1-dev
> @@ -1480,7 +1486,8 @@ @subsection Inter-package dependencies
> Rule: If the package maintainer chooses the @emph{No coexistence
> allowed} policy, the @code{-dev} package's @file{debian/control} file
> SHALL contain @samp{Conflicts:} and @samp{Replaces:} lines listing all
> -previous versions of the package, if any.
> +previous versions of the package, if any, that ever depended on the
> +same @code{gnat-X.Y} package.
After reading this paragraph (the only one I refer to while working on a
concrete package), I understand that libconfig2-dev
Conflicts:
Replaces:
At least one of the two should be more explicit.
In the same policy section, I suggest for completeness something like
Rule: the -dev package SHALL Depend: on the packages gnat, gnat-X,Y,
ada-compiler and the exact version of the corresponding shared library
package.
Rationale: (as before and) Depending on the shared library ensures that
the /usr/lib symbolic link refers to an installed file.
even if this is evident in the context and ${misc:Depends} seems to handle
that automatically.
Thirdly, I am not an expert in debuggers, but I believe that -dbg is not
very useful without the source code. Why not
dev Depends library
dbg Depends library
dbg Recommends dev
or even
dbg Depends dev
dev Depends library
Reply to: