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 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
