Brian May wrote: > That makes more sense. dh_make in slink doesn't do this though, potato > might be different.
Debhelper's example rules files have always done this, though I cannot speak for dh-make. > My observation (nothing more/less, however, probably a good idea > in general): > > This means that it is the debian maintainer's decision to have a > SetUID program, not the upstream maintainer (as dh_fixperms overrides > anything set by the upstream Makefile). > > At least, the Debian maintainer must be aware of programs that are > SetUID. Yes, that's exactly the idea. I don't want a new upstream release of a package I maintain introducing a new suid binary and me missing it and not auditing it before putting it in debian. I'm paranoid about this and here debhelper reflects my paranoia. Of course, it also lets you reorder the commands any way you like, or not even call dh_fixperms. -- see shy jo
