Bug#790125: RFS: dropbear/2015.67-1.1 NMU
Control: tags -1 - moreinfo
Hi Guilhem,
That was quick. Let me answer some of your comments already. I intend to
take another stab at the upload when I find more time, but that shall
not prevent other interested sponsors from uploading it earlier.
Possibly Gerrit replied by then.
On Fri, Jul 31, 2015 at 05:44:09AM +0200, Guilhem Moulin wrote:
> In fact in a later mail in the d-d thread Gerrit agreed to make
> “dropbear” a transitional package and place binaries to “dropbear-bin”,
> as suggested to me by Adam Borowski:
>
> https://lists.debian.org/debian-devel/2015/06/msg00290.html
I must have missed that while scanning the thread. Thanks.
> > Since dropbear-initramfs relies on initramfs-tools 0.94 features, the
> > dependency should be versioned.
>
> Thanks, fixed. (Didn't think it mattered since even oldoldstable has
> said feature.)
Your remark is very relevant here. That's a good reason to do an
unversioned dependency. I simply forgot to look up when 0.94 was
released.
> Alright, this one is new to me. I'm not sure how blindly I can follow
>
> https://wiki.debian.org/Multiarch/Implementation#dh.281.29_and_autotools
>
> because dropbear-bin ships an executable ‘/usr/lib/dropbear/dropbearconvert’.
> So checked the package source for openssh and found that openssh-server
> uses Multi-Arch:foreign, but openssh-sftp-server, which ships
> ‘/usr/lib/openssh/sftp-server’, doesn't. So all in all I'm unsure what
> to in my case.
It is actually much easier than that. Since dropbear does not ship any
libraries or similar, the only Multi-Arch tag that makes sense is
"foreign". So this is mostly a matter of asking: Does a package expose
its architecture via one of its public interfaces? If the answer is
"no", then "foreign" is appropriate.
Let me give examples what exposure means here. gcc creates ELF objects.
So by compiling a .c file you get different output per architecture.
Anything that contains a shared library generally exposes the
architecture. A special example is pkg-config. It is marked M-A:foreign,
but the output of pkg-config foo --libdir often depends on the
architecture of pkg-config. Here, it is considered that pkg-config is
not part of the public interface (from a Multi-Arch pov) and one should
run $(DEB_HOST_GNU_TYPE)-pkg-config instead (which autotools do).
Another special example is locales (which is Arch:all). It compiles
locales during postinst and exposes the native architecture via those
files generated during postinst.
I didn't spot any reason for not marking all of the dropbear packages
M-A:foreign, but this probably warrants a closer look.
> Yes, it's to make dh_installdocs happy, and avoid it spitting
>
> WARNING: --link-doc between architecture all and not all packages breaks binNMUs
>
> What are you suggesting as an alternative?
There is a tradeoff to be made here. You can always consider not using
--link-doc. Since the documentation directory is fairly small for
dropbear, little is gained by using --link-doc (embedded installations
that want to shrink the system can always add
--path-exclude=/usr/share/doc/* to dpkg, which is guaranteed to work by
the policy). Furthermore, not using --link-doc allows partitioning the
documentation to make it easier to find. There is no right or wrong way
here.
> That said I'm happy to learn more and I have added the header already.
Removing moreinfo accordingly. In future, please remove the tag yourself
when addressing the reason it was added.
> No I *extend* CFLAGS with -DSFTPSERVER_PATH='"/usr/lib/sftp-server"'.
> Aren't CPPFLAGS and LDFLAGS passed as is already? The build log seems
> to suggests it at least.
Oh right. Seeing CFLAGS on the command line, it didn't occur to me that
the other variables would go via the environment. Thanks for clarifying.
> That said, while I understand the heavy changelog is frown upon by
> potential sponsors, I have to say I would find it quite frustrating if
> my work on this package, including the fixes to the many bugs regarding
> dropbear-initramfs (which I heavily rely on in my own infrastructure),
> wasn't eventually uploaded :-P
I do hope that all of these changes land in stretch.
Helmut
Reply to: