On 2020-12-18, Keith Winstein wrote: > Hi, sorry, I should have clarified that I am also the upstream maintainer, > and I keep the "debian" directory in the same source repository as > everything else. That's what I meant about submitting a pull request on > GitHub. It would still be a modification to debian/rules.
Ah, got it! > The backstory here is that because those mahimahi programs (mm-link, > mm-delay, mm-onoff, mm-loss, mm-webrecord, mm-webreplay) run setuid root, > we are paranoid about using PATH at runtime. Makes sense. > So we try to resolve these absolute pathnames at build-time. If Debian > wants to hardcode the locations, fine with me. The problem with hard-coding at build time is unfortunately it produces packages that only work with systems with the same path locations, and at least on Debian systems, both usrmerge and non-usrmerge systems exist in the real world. > I am curious -- why is it important that builds be identical between > usrmerge systems and non-usrmerge systems? Because /usr/sbin/iptables is only present on usrmerge systems, if you hard-code the paths, then it will only work on usrmerge systems. There are typically compatibility symlinks /sbin -> /usr/sbin, so hard-coding the other way around is ... less bad... :) > It's not like we try to have builds be identical between systems with > different versions of the compiler, etc. True! Since the binaries paths might be in either location, we attempt to detect such situations are part of reproducible builds tests, and it makes it easier for someone to manually verify a build without having to know if it is a usrmerge vs. non-usrmerge build environment; e.g. it ideally builds the same regardless. > Still, though, if this is the notion of reproducibility that > Debian wants its packages to have, I'm happy to comply and have no quibbles > with your patch. Great! Will submit a merge request soon. live well, vagrant
signature.asc
Description: PGP signature
