Control: tags -1 -moreinfo Dear Boyuan,
Thank you for your interest and asking the questions: Le jeudi 11 août 2022, 21:27:14 CEST Boyuan Yang a écrit : > I am curious on the current arrangement of your deb packaging. Specifically: > > * Why there are many separate ffs_* patches in debian/patches/? Where did > they originate from? If they originates from upstream (FreeFileSync), why > aren't they incorporated into upstream source code? Originally I found packaging for Devuan but also for Ubuntu on non official repos [1] & [2]. FreeFileSync has been packaged for years at least for Ubuntu but was never on Debian. So I took a lot of inspiration of these 2 packages to make this one. This also explains the list of authors in the d/copyright file. I also didn't known what to do with the history. Both packages share the same patches, but their d/ changelog doesn't cross each-other. Concerning the patches, I took them from bgstack15's repo [1]. BTW Most patches have his name/nickname in the patch headers. He also describes them with the rationale in the header. I did too for the ones I added by following DEP-3 Patch Tagging guidelines. Some patches are here because upstream works with the very latest versions of the dependencies or an older version, which are not always available on debian & derivatives. That's the case for wxwidgets-3.2 or gtk-2: - revert_zenju_aggressive_upstreamisms.patch - ffs_no_wx311.patch - ffs_devuan_gtk3.patch Some patches add, enable, remove or disable a feature (notification, check for updates...) - ffs_allow_parallel_ops.patch - ffs_traditional_view.patch - ffs_no_check_updates.patch - ffs_desktop_notifications.patch Some patches are to make it compatible with debian filesystem or build system - ffs_gcc.patch - ffs_devuan.patch - reproducible-build.patch - pkg-config.patch This one is probably to distinguish between the free version for which the code is published, and the binary builds that the author ships to donators. - ffs_dpkg_vendor_specific_about.patch Some patches fix upstream's code which is not buildable otherwise (either we don't have the same dependency version as the one used by upstream which leads to compilation errors, or he uses unavailable macro's that have to be patched) - ffs_sftp.patch - ffs_icon_loader.patch I sent mine upstream (pgk-config & reproducible) by email. Hopefully they will be merged. But on github, upstream says: "Please do not send pull requests" [3]. > * You are providing .desktop files under debian/desktop/. Does that mean > that upstream author is not providing any .desktop files so that you have to > write them yourself? Indeed. They are not available in the original sources shipped by the upstream author. However he/she provides some in his linux installer binary that I took manually from there. I also adapted them based also on the additions/changes found in the desktop files shipped in the Ubuntu & Devuan sources. > * Please do not hardcode g++-12:native in the Build-Depends field. A sane > environment should already have provided the proper g++. It could be g++ 12 > or other versions. That's fixed. Thanks. https://salsa.debian.org/bastif/freefilesync/-/commit/ a57b5655814b46559d875548526bfecc6690b269 > * You wrote Maintainer: B. Stack <bgstac...@gmail.com> in debian/control > file, which looks falty to me. The maintainer should be package maintainer, > not upstream software author, unless the upstream author (B. Stack) will be > maintaining Debian package as well. That was originally in the d/control I took from him. I left it this way not really knowing what would be best. I talked to him, he would be happy to see this in Debian and said that he might take the package over once in Debian. I don't know exactly what he meant. What do you suggest in the meantime? > * You indicated "Multi-Arch: foreign" in debian/control file. However > according to https://wiki.debian.org/MultiArch/Hints#ma-foreign , M-A: > foreign only applies to Architecture: all packages. Your package is not of > Architecture: all. That's not what I understood from that paragraph. The rest of the paragraph suggests that foreign can also be for Architecture: any. Many packages have such a setup. Just an example: https://sources.debian.org/src/zip/3.0-12/debian/control/ Manpage of deb-control states foreign This package is not co-installable with itself, but should be allowed to satisfy a non-arch-qualified dependency of a package of a different arch from itself (if a dependency has an explicit arch- qualifier then the value foreign is ignored). I'm not sure to totally understand what is written here, but I understant that with "foreign" we can't install freefilesync:amd64 & freefilesync:i386 at the same time. But we can have a setup where we could have freefilesync:i386 installed on an amd64 system (with an additional arch of i386) - if it were a dependency of a i386 package (??) -. Is this correct? [1] https://gitlab.com/bgstack15/stackrpms/-/tree/master/freefilesync [2] https://launchpad.net/~xtradeb/+archive/ubuntu/apps/+packages? field.name_filter=sync&field.status_filter=published&field.series_filter= [3] https://github.com/hkneptune/FreeFileSync Rgds Fab
