Bug#1012325: dialog: Multi-Arch: foreign package should not contain static library

[Sven Joachim]

Package: dialog
Version: 1.3-20211214-1
Severity: normal
User: multiar...@lists.alioth.debian.org
Usertags: multiarch

The dialog package is marked Multi-Arch: foreign, but contains the
static library /usr/lib/<triplet>/libdialog.a. This is flagged as an
error by lintian.

,----
| $ lintian-explain-tags multiarch-foreign-static-library
| N:
| E: multiarch-foreign-static-library
| N:
| N: The package is architecture-dependent, ships a static library in a public, architecture-dependent library search path
| N: and is marked Multi-Arch: foreign. A compiler will be unable to find this file, unless it is installed for a matching
| N: architecture, but the foreign marking says that the architecture should not matter.
| N:
| N: Please remove the Multi-Arch: foreign stanza.
`----

The lintian diagnosis looks correct to me, but I do not think the
suggested remedy is what we want here. Rather, the correct fix should
be to split out libdialog.a and the header files into a separate
libdialog-dev package (which probably could be marked Multi-Arch: same).


-- System Information:
Debian Release: bookworm/sid
APT prefers unstable
APT policy: (500, 'unstable'), (101, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.10.119-nouveau (SMP w/2 CPU threads)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages dialog depends on:
ii debianutils 5.7-0.2
ii libc6 2.33-7
ii libncursesw6 6.3+20220423-2
ii libtinfo6 6.3+20220423-2

dialog recommends no packages.

dialog suggests no packages.

-- no debconf information

[Sven Joachim]

Control: tags -1 + patch

On 2022-06-04 09:52 +0200, Sven Joachim wrote:

> Package: dialog
> Version: 1.3-20211214-1
> Severity: normal
> User: multiar...@lists.alioth.debian.org
> Usertags: multiarch
>
> The dialog package is marked Multi-Arch: foreign, but contains the
> static library /usr/lib/<triplet>/libdialog.a. This is flagged as an
> error by lintian.
>
> ,----
> | $ lintian-explain-tags multiarch-foreign-static-library
> | N:
> | E: multiarch-foreign-static-library
> | N:
> | N: The package is architecture-dependent, ships a static library in a public, architecture-dependent library search path
> | N: and is marked Multi-Arch: foreign. A compiler will be unable to find this file, unless it is installed for a matching
> | N: architecture, but the foreign marking says that the architecture should not matter.
> | N:
> | N: Please remove the Multi-Arch: foreign stanza.
> `----
>
> The lintian diagnosis looks correct to me, but I do not think the
> suggested remedy is what we want here. Rather, the correct fix should
> be to split out libdialog.a and the header files into a separate
> libdialog-dev package (which probably could be marked Multi-Arch: same).

See the attached patch which is build-time tested. The package
description for libdialog-dev might have to be tweaked, and if
1.3-20211214-2 is not the version that first applies the patch, the
Breaks/Replaces relationships need to be adjusted.

I also noticed that dialog.h #includes curses.h, so added a dependency
on libncurses-dev to libdialog-dev.

Cheers,
Sven

[Thomas Dickey]

On Sat, Jun 04, 2022 at 11:19:20AM +0200, Sven Joachim wrote:
> Control: tags -1 + patch
>
> On 2022-06-04 09:52 +0200, Sven Joachim wrote:
>
> > Package: dialog
> > Version: 1.3-20211214-1
> > Severity: normal
> > User: multiar...@lists.alioth.debian.org
> > Usertags: multiarch
> >
> > The dialog package is marked Multi-Arch: foreign, but contains the
> > static library /usr/lib/<triplet>/libdialog.a. This is flagged as an
> > error by lintian.

actually, a shared library is generally preferred for development packages.
This is what I build for my own use (scripts in the package/debian directory),
as "cdialog-dev":

/usr/bin/cdialog-config*
/usr/include/cdialog/dlg_colors.h
/usr/include/cdialog/dlg_config.h
/usr/include/cdialog/dlg_keys.h
/usr/include/cdialog.h
/usr/share/doc/cdialog-dev/changelog.Debian.gz
/usr/share/doc/cdialog-dev/changelog.gz
/usr/share/doc/cdialog-dev/copyright
/usr/share/man/man3/cdialog.3.gz
/lib/x86_64-linux-gnu/libcdialog.so@

Adding a static library is helpful, of course.

> > ,----
> > | $ lintian-explain-tags multiarch-foreign-static-library
> > | N:
> > | E: multiarch-foreign-static-library
> > | N:
> > | N: The package is architecture-dependent, ships a static library in a public, architecture-dependent library search path
> > | N: and is marked Multi-Arch: foreign. A compiler will be unable to find this file, unless it is installed for a matching
> > | N: architecture, but the foreign marking says that the architecture should not matter.
> > | N:
> > | N: Please remove the Multi-Arch: foreign stanza.
> > `----
> >
> > The lintian diagnosis looks correct to me, but I do not think the
> > suggested remedy is what we want here. Rather, the correct fix should
> > be to split out libdialog.a and the header files into a separate
> > libdialog-dev package (which probably could be marked Multi-Arch: same).
>
> See the attached patch which is build-time tested. The package
> description for libdialog-dev might have to be tweaked, and if
> 1.3-20211214-2 is not the version that first applies the patch, the
> Breaks/Replaces relationships need to be adjusted.
>
> I also noticed that dialog.h #includes curses.h, so added a dependency
> on libncurses-dev to libdialog-dev.
>
> Cheers,
> Sven
>

> diff --git a/debian/control b/debian/control
> index 14ddb48..a38a59b 100644
> --- a/debian/control
> +++ b/debian/control
> @@ -9,7 +9,6 @@ Homepage: https://invisible-island.net/dialog/dialog.html
> Package: dialog
> Architecture: any
> Depends: ${shlibs:Depends}, debianutils (>= 1.6)
> -Provides: libdialog-dev
> Multi-Arch: foreign
> Description: Displays user-friendly dialog boxes from shell scripts
> This application provides a method of displaying several different types
> @@ -29,3 +28,17 @@ Description: Displays user-friendly dialog boxes from shell scripts
> tail Allows viewing the end of files (tail) that auto updates
> background tail Similar to tail but runs in the background.
> editbox Allows editing an existing file
> +
> +Package: libdialog-dev
> +Architecture: any
> +Section: libdevel
> +Depends: ${misc:Depends}, libncurses-dev
> +Multi-Arch: same
> +Replaces: dialog (<< 1.3-20211214-2~)
> +Breaks: dialog (<< 1.3-20211214-2~)
> +Description: Displays user-friendly dialog boxes -- development files
> + The dialog application provides a method of displaying several different
> + types of dialog boxes from shell scripts. This allows a developer of a
> + script to interact with the user in a much friendlier manner.
> + .
> + This package contains the header files and the static library.
> diff --git a/debian/dialog.install b/debian/dialog.install
> index 891ffa2..7186321 100644
> --- a/debian/dialog.install
> +++ b/debian/dialog.install
> @@ -1 +1,4 @@
> dialog.pl usr/share/perl5
> +usr/bin
> +usr/share/locale
> +usr/share/man/man1
> diff --git a/debian/libdialog-dev.install b/debian/libdialog-dev.install
> new file mode 100644
> index 0000000..95c4b91
> --- /dev/null
> +++ b/debian/libdialog-dev.install
> @@ -0,0 +1,3 @@
> +usr/include
> +usr/lib
> +usr/share/man/man3


--
Thomas E. Dickey <dic...@invisible-island.net>
https://invisible-island.net
ftp://ftp.invisible-island.net

[Santiago Vila]

Thanks a lot for the patch.

Yes, it would make sense to move *.h and .a to a libdialog-dev package.

But I'm not sure about the best way to proceed after reading the reply from Thomas:

> actually, a shared library is generally preferred for development packages.
> This is what I build for my own use (scripts in the package/debian directory),
> as "cdialog-dev":
>
> /usr/bin/cdialog-config*
> /usr/include/cdialog/dlg_colors.h
> /usr/include/cdialog/dlg_config.h
> /usr/include/cdialog/dlg_keys.h
> /usr/include/cdialog.h
> /usr/share/doc/cdialog-dev/changelog.Debian.gz
> /usr/share/doc/cdialog-dev/changelog.gz
> /usr/share/doc/cdialog-dev/copyright
> /usr/share/man/man3/cdialog.3.gz
> /lib/x86_64-linux-gnu/libcdialog.so@

In Debian the static library has always been named libdialog.a,
but the library according to the author is called libcdialog.so.

If I go ahead and create a shared library package (which I suspect is
the only thing ftpmasters will accept if they see NEW binary packages),
should I worry about binary compatibility with other distros?

Thanks.

[Thomas Dickey]

On Thu, Jan 05, 2023 at 04:05:29PM +0100, Santiago Vila wrote:
> Thanks a lot for the patch.
>
> Yes, it would make sense to move *.h and .a to a libdialog-dev package.
>
> But I'm not sure about the best way to proceed after reading the reply from Thomas:
>
> > actually, a shared library is generally preferred for development packages.
> > This is what I build for my own use (scripts in the package/debian directory),
> > as "cdialog-dev":
> >
> > /usr/bin/cdialog-config*
> > /usr/include/cdialog/dlg_colors.h
> > /usr/include/cdialog/dlg_config.h
> > /usr/include/cdialog/dlg_keys.h
> > /usr/include/cdialog.h
> > /usr/share/doc/cdialog-dev/changelog.Debian.gz
> > /usr/share/doc/cdialog-dev/changelog.gz
> > /usr/share/doc/cdialog-dev/copyright
> > /usr/share/man/man3/cdialog.3.gz
> > /lib/x86_64-linux-gnu/libcdialog.so@
>
> In Debian the static library has always been named libdialog.a,
> but the library according to the author is called libcdialog.so.

A development package could have both static and dynamic libraries.
dialog can build either, but not both at the same time (just like ncurses).

> If I go ahead and create a shared library package (which I suspect is
> the only thing ftpmasters will accept if they see NEW binary packages),
> should I worry about binary compatibility with other distros?
>
> Thanks.
>

[Santiago Vila]

El 6/1/23 a las 0:39, Thomas Dickey escribió:

> On Thu, Jan 05, 2023 at 04:05:29PM +0100, Santiago Vila wrote:
>> In Debian the static library has always been named libdialog.a,
>> but the library according to the author is called libcdialog.so.
>
> A development package could have both static and dynamic libraries.
> dialog can build either, but not both at the same time (just like ncurses).

Ok, I didn't know, but the thing which I'm worried about is
really libdialog vs libcdialog, not ".a" vs ".so".

(sorry for mixing both things)

To be more precise: Are there any applications in the wild linked
against libcdialog.so which would not run in a Debian system
if I decide to provide libdialog.so in the Debian package?

Thanks.

[Thomas Dickey]

----- Original Message -----
| From: "Santiago Vila" <san...@debian.org>
| To: "Thomas Dickey" <dic...@his.com>, 101...@bugs.debian.org
| Cc: "Sven Joachim" <sven...@gmx.de>
| Sent: Thursday, January 5, 2023 7:09:22 PM
| Subject: Bug#1012325: dialog: Multi-Arch: foreign package should not contain static library

| El 6/1/23 a las 0:39, Thomas Dickey escribió:
|> On Thu, Jan 05, 2023 at 04:05:29PM +0100, Santiago Vila wrote:
|>> In Debian the static library has always been named libdialog.a,
|>> but the library according to the author is called libcdialog.so.
|>
|> A development package could have both static and dynamic libraries.
|> dialog can build either, but not both at the same time (just like ncurses).
|
| Ok, I didn't know, but the thing which I'm worried about is
| really libdialog vs libcdialog, not ".a" vs ".so".

I name my Dialog package with a "c" to allow me to have
both the Debian and my test-package installed without conflict.

(I do this for most of my test-packages, because it's otherwise awkward to
respond to bug-reports)

My comment about the layout was in more general terms,
to show how it might be reorganized to provide the development library.

| (sorry for mixing both things)
|
| To be more precise: Are there any applications in the wild linked
| against libcdialog.so which would not run in a Debian system
| if I decide to provide libdialog.so in the Debian package?

very few people (aside from me) use my test-packages :-)