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 -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150731054625.ga22...@alf.mars
