Bug#1012325: dialog: Multi-Arch: foreign package should not contain static library
Hi. I have made the upload. But now I remember that this may get rejected for requiring new binary packages (not sure if this has changed since the last time), so wish me luck... Thanks a lot for all the help!
Bug#1012325: dialog: Multi-Arch: foreign package should not contain static library
On 2024-04-06 21:45 +0200, Santiago Vila wrote: > El 6/4/24 a las 20:53, Sven Joachim escribió: >> 1. https://www.debian.org/doc/debian-policy/ch-relationships.html#id11 > > Ok, I had not read that part of Policy in a long time. > > One minor last thing: > > Assuming I make the changes and package the new available > upstream version at the same time, can I simplify the breaks > and replaces to just "(<< 1.3-20240307)"? Yes, that should be fine. Cheers, Sven
Bug#1012325: dialog: Multi-Arch: foreign package should not contain static library
El 6/4/24 a las 20:53, Sven Joachim escribió: 1. https://www.debian.org/doc/debian-policy/ch-relationships.html#id11 Ok, I had not read that part of Policy in a long time. One minor last thing: Assuming I make the changes and package the new available upstream version at the same time, can I simplify the breaks and replaces to just "(<< 1.3-20240307)"? Thanks.
Bug#1012325: dialog: Multi-Arch: foreign package should not contain static library
On 2024-04-06 19:49 +0200, Santiago Vila wrote: >> Patch attached, I have tested that it builds on amd64 and i386. looked >> at the generated Dependencies and verified that lintian does not go >> crazy, but that's it. Note that I had to add libtool-bin rather than >> just libtool to Build-Depends to prevent configure from complaining, and >> also pacify dh_missing considering the not installed .la file. > > Awesome, thanks a lot! > > Regarding the static library, I can see now that keeping it does not > really make the package more complex, so we'll keep it. > > A few questions: > > - Does this require a "transition"? I think not, because the API has not > changed. On the other hand, packages which build-depend on libdialog-dev > should be rebuilt with the shared library anyway, and this is usually done > as part of a transition. Considering that there are currently no packages in unstable which build-depend on libdialog-dev (or on dialog, for that matter), a transition seems unnecessary. > - Regarding the Breaks field, I think it's not actually required and > we should not add it (i.e. Replaces is enough). Policy disagrees, and the piuparts maintainer might come after you if they detect that. > I tried creating the packages without the Breaks field, installing the > libdialog and libdialog-dev packages on a system where dialog was > already installed, and this is what happened: > > # dpkg -i libdialog-dev_1.3-20240101-2_amd64.deb > libdialog15_1.3-20240101-2_amd64.deb > (Reading database ... 14174 files and directories currently installed.) > Preparing to unpack libdialog-dev_1.3-20240101-2_amd64.deb ... > Unpacking libdialog-dev:amd64 (1.3-20240101-2) ... > Replacing files in old package dialog (1.3-20240101-1) ... > Preparing to unpack libdialog15_1.3-20240101-2_amd64.deb ... > Unpacking libdialog15:amd64 (1.3-20240101-2) over (1.3-20240101-2) ... > Setting up libdialog15:amd64 (1.3-20240101-2) ... > Setting up libdialog-dev:amd64 (1.3-20240101-2) ... > Processing triggers for man-db (2.12.1-1) ... > Not building database; man-db/auto-update is not 'true'. > Processing triggers for libc-bin (2.37-15.1) ... > > i.e. no errors, dpkg takes note of the moved files, and the old dialog > is still functional, because it's still linked statically. Yes, but if you then decide to remove the libdialog-dev package, the libdialog.a file is gone, although the old dialog package supposedly still provides libdialog-dev. That is the reason why Policy recommends to use "Replaces" in combination with "Breaks"[1]. Cheers, Sven 1. https://www.debian.org/doc/debian-policy/ch-relationships.html#id11
Bug#1012325: dialog: Multi-Arch: foreign package should not contain static library
Patch attached, I have tested that it builds on amd64 and i386. looked at the generated Dependencies and verified that lintian does not go crazy, but that's it. Note that I had to add libtool-bin rather than just libtool to Build-Depends to prevent configure from complaining, and also pacify dh_missing considering the not installed .la file. Awesome, thanks a lot! Regarding the static library, I can see now that keeping it does not really make the package more complex, so we'll keep it. A few questions: - Does this require a "transition"? I think not, because the API has not changed. On the other hand, packages which build-depend on libdialog-dev should be rebuilt with the shared library anyway, and this is usually done as part of a transition. - Regarding the Breaks field, I think it's not actually required and we should not add it (i.e. Replaces is enough). I tried creating the packages without the Breaks field, installing the libdialog and libdialog-dev packages on a system where dialog was already installed, and this is what happened: # dpkg -i libdialog-dev_1.3-20240101-2_amd64.deb libdialog15_1.3-20240101-2_amd64.deb (Reading database ... 14174 files and directories currently installed.) Preparing to unpack libdialog-dev_1.3-20240101-2_amd64.deb ... Unpacking libdialog-dev:amd64 (1.3-20240101-2) ... Replacing files in old package dialog (1.3-20240101-1) ... Preparing to unpack libdialog15_1.3-20240101-2_amd64.deb ... Unpacking libdialog15:amd64 (1.3-20240101-2) over (1.3-20240101-2) ... Setting up libdialog15:amd64 (1.3-20240101-2) ... Setting up libdialog-dev:amd64 (1.3-20240101-2) ... Processing triggers for man-db (2.12.1-1) ... Not building database; man-db/auto-update is not 'true'. Processing triggers for libc-bin (2.37-15.1) ... i.e. no errors, dpkg takes note of the moved files, and the old dialog is still functional, because it's still linked statically. Thanks.
Bug#1012325: dialog: Multi-Arch: foreign package should not contain static library
On Sat, Mar 30, 2024 at 08:02:18PM +0100, Sven Joachim wrote:
> On 2024-03-30 12:38 +0100, Santiago Vila wrote:
>
> > El 30/3/24 a las 9:43, Sven Joachim escribió:
> >> I think it would make sense for Debian to follow what Arch and Fedora
> >> are doing, introduce a libdialog15 package with the shared library and a
> >> libdialog-dev package with the .so symlink but without libdialog.a,
> >> because that requires (if I understood you correctly) configuring and
> >> building dialog twice, greatly complicating packaging.
> >> Santiago, do you think this is a good plan?
> >
> > Yes. If we can avoid the static library to keep it simple, that would be
> > better.
> >
> > Simple question: Is that really allowed these days? I wanted to be sure
> > by reading Policy but did not find any statement saying they are required
> > or not.
>
> I could only find the following two sentences in §8.3:
>
> ,
> | The static library ("libraryname.a") is usually provided in addition
> | to the shared version. It is placed into the development package (see
> | below).
> `
>
> So shipping static libraries is recommended but not required, and there
> are certainly quite a few packages where upstream does not support them.
> But see below.
Actually, for development on MacOS, I have to use static libraries,
because there's no useful analog for LD_LIBRARY_PATH :-)
> >> I can work on an updated patch.
> >
> > That would definitely help.
>
> This afternoon I got my hands dirty. The first attempt to simply pass
> --with-shared to configure failed to give me a libdialog.a, and it also
> produced the following odd collection of *.so* files:
>
> libdialog.so -> libdialog.so.15.0.0
> libdialog.so.1.3
> libdialog.so.15.0.0 -> libdialog.so.1.3
fwiw, ncurses, dialog and cdk use the same scripts (and version information)
> Not what you would expect, and it does not match the files shipped in
> the Fedora and Arch packages. A closer look revealed that they both
> configure dialog --with-libtool, and that worked great because it gave
> me not only the expected layout of *.so* files, but also a static
> libdialog.a library. :-)
perhaps - but since aside from Linux, libtool support is not reliable,
it's not going to be of primary concern to me.
--
Thomas E. Dickey
https://invisible-island.net
signature.asc
Description: PGP signature
Bug#1012325: dialog: Multi-Arch: foreign package should not contain static library
On 2024-03-30 12:38 +0100, Santiago Vila wrote:
> El 30/3/24 a las 9:43, Sven Joachim escribió:
>> I think it would make sense for Debian to follow what Arch and Fedora
>> are doing, introduce a libdialog15 package with the shared library and a
>> libdialog-dev package with the .so symlink but without libdialog.a,
>> because that requires (if I understood you correctly) configuring and
>> building dialog twice, greatly complicating packaging.
>> Santiago, do you think this is a good plan?
>
> Yes. If we can avoid the static library to keep it simple, that would be
> better.
>
> Simple question: Is that really allowed these days? I wanted to be sure
> by reading Policy but did not find any statement saying they are required
> or not.
I could only find the following two sentences in §8.3:
,
| The static library ("libraryname.a") is usually provided in addition
| to the shared version. It is placed into the development package (see
| below).
`
So shipping static libraries is recommended but not required, and there
are certainly quite a few packages where upstream does not support them.
But see below.
>> I can work on an updated patch.
>
> That would definitely help.
This afternoon I got my hands dirty. The first attempt to simply pass
--with-shared to configure failed to give me a libdialog.a, and it also
produced the following odd collection of *.so* files:
libdialog.so -> libdialog.so.15.0.0
libdialog.so.1.3
libdialog.so.15.0.0 -> libdialog.so.1.3
Not what you would expect, and it does not match the files shipped in
the Fedora and Arch packages. A closer look revealed that they both
configure dialog --with-libtool, and that worked great because it gave
me not only the expected layout of *.so* files, but also a static
libdialog.a library. :-)
Patch attached, I have tested that it builds on amd64 and i386. looked
at the generated Dependencies and verified that lintian does not go
crazy, but that's it. Note that I had to add libtool-bin rather than
just libtool to Build-Depends to prevent configure from complaining, and
also pacify dh_missing considering the not installed .la file.
There are certainly a few improvements possible (e.g. adding a symbols
file, testing R³ support), I leave this up to you.
Cheers,
Sven
diff -Nru dialog-1.3-20240101/debian/changelog dialog-1.3-20240101/debian/changelog
--- dialog-1.3-20240101/debian/changelog 2024-01-23 18:05:00.0 +0100
+++ dialog-1.3-20240101/debian/changelog 2024-03-30 19:21:27.0 +0100
@@ -1,3 +1,11 @@
+dialog (1.3-20240101-2) UNRELEASED; urgency=medium
+
+ * Split out libdialog-dev into its own package. Closes: #1012325.
+ * Build a shared library.
+ * Add libtool-bin to Build-Depends.
+
+ -- Sven Joachim Sat, 30 Mar 2024 19:21:27 +0100
+
dialog (1.3-20240101-1) unstable; urgency=medium
* New upstream release.
diff -Nru dialog-1.3-20240101/debian/control dialog-1.3-20240101/debian/control
--- dialog-1.3-20240101/debian/control 2024-01-23 17:00:00.0 +0100
+++ dialog-1.3-20240101/debian/control 2024-03-30 19:21:27.0 +0100
@@ -3,13 +3,12 @@
Priority: optional
Maintainer: Santiago Vila
Standards-Version: 4.6.2
-Build-Depends: debhelper-compat (= 13), gettext, libncurses-dev (>= 5.3)
+Build-Depends: debhelper-compat (= 13), gettext, libncurses-dev (>= 5.3), libtool-bin
Homepage: https://invisible-island.net/dialog/dialog.html
Package: dialog
Architecture: any
Depends: debianutils (>= 1.6), ${misc:Depends}, ${shlibs:Depends}
-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,29 @@
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: libdialog15
+Architecture: any
+Section: libs
+Depends: ${misc:Depends}, ${shlibs:Depends}
+Multi-Arch: same
+Description: Displays user-friendly dialog boxes -- shared library
+ 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 shared library.
+
+Package: libdialog-dev
+Architecture: any
+Section: libdevel
+Depends: ${misc:Depends}, libdialog15 (= ${binary:Version}), libncurses-dev
+Multi-Arch: same
+Replaces: dialog (<< 1.3-20240101-2~)
+Breaks: dialog (<< 1.3-20240101-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 development files and the API documentation.
diff -Nru
Bug#1012325: dialog: Multi-Arch: foreign package should not contain static library
El 30/3/24 a las 9:43, Sven Joachim escribió: I think it would make sense for Debian to follow what Arch and Fedora are doing, introduce a libdialog15 package with the shared library and a libdialog-dev package with the .so symlink but without libdialog.a, because that requires (if I understood you correctly) configuring and building dialog twice, greatly complicating packaging. Santiago, do you think this is a good plan? Yes. If we can avoid the static library to keep it simple, that would be better. Simple question: Is that really allowed these days? I wanted to be sure by reading Policy but did not find any statement saying they are required or not. I can work on an updated patch. That would definitely help. Thanks a lot!
Bug#1012325: dialog: Multi-Arch: foreign package should not contain static library
On 2023-01-05 20:32 -0500, Thomas Dickey wrote: > - Original Message - > | From: "Santiago Vila" > | To: "Thomas Dickey" , 1012...@bugs.debian.org > | Cc: "Sven Joachim" > | 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. I had a look at the dialog package list for Arch Linux[1] and Fedora Rawhide[2], and they both ship libdialog.so, libdialog.so.15 and libdialog.so.15.0.0. There is no libcdialog.so, nor a static 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 :-) I think it would make sense for Debian to follow what Arch and Fedora are doing, introduce a libdialog15 package with the shared library and a libdialog-dev package with the .so symlink but without libdialog.a, because that requires (if I understood you correctly) configuring and building dialog twice, greatly complicating packaging. Santiago, do you think this is a good plan? I can work on an updated patch. Cheers, Sven 1. https://archlinux.org/packages/core/x86_64/dialog/ 2. https://fedora.pkgs.org/rawhide/fedora-x86_64/dialog-1.3-50.20240101.fc40.x86_64.rpm.html
Bug#1012325: dialog: Multi-Arch: foreign package should not contain static library
- Original Message - | From: "Santiago Vila" | To: "Thomas Dickey" , 1012...@bugs.debian.org | Cc: "Sven Joachim" | 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 :-) -- Thomas E. Dickey https://invisible-island.net
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". (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.
Bug#1012325: dialog: Multi-Arch: foreign package should not contain static library
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. > -- Thomas E. Dickey https://invisible-island.net signature.asc Description: PGP signature
Bug#1012325: dialog: Multi-Arch: foreign package should not contain static library
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.
Bug#1012325: dialog: Multi-Arch: foreign package should not contain static library
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: multiarch-de...@lists.alioth.debian.org
> > Usertags: multiarch
> >
> > The dialog package is marked Multi-Arch: foreign, but contains the
> > static library /usr/lib//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 000..95c4b91
> --- /dev/null
> +++ b/debian/libdialog-dev.install
> @@ -0,0 +1,3 @@
> +usr/include
> +usr/lib
> +usr/share/man/man3
--
Thomas E. Dickey
https://invisible-island.net
ftp://ftp.invisible-island.net
signature.asc
Description: PGP signature
Bug#1012325: dialog: Multi-Arch: foreign package should not contain static library
Control: tags -1 + patch
On 2022-06-04 09:52 +0200, Sven Joachim wrote:
> Package: dialog
> Version: 1.3-20211214-1
> Severity: normal
> User: multiarch-de...@lists.alioth.debian.org
> Usertags: multiarch
>
> The dialog package is marked Multi-Arch: foreign, but contains the
> static library /usr/lib//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
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 000..95c4b91
--- /dev/null
+++ b/debian/libdialog-dev.install
@@ -0,0 +1,3 @@
+usr/include
+usr/lib
+usr/share/man/man3
Bug#1012325: dialog: Multi-Arch: foreign package should not contain static library
Package: dialog Version: 1.3-20211214-1 Severity: normal User: multiarch-de...@lists.alioth.debian.org Usertags: multiarch The dialog package is marked Multi-Arch: foreign, but contains the static library /usr/lib//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
