> > Well, maybe it should and the bug is somewhere else (for example, > > whatever program is creating the buildinfo file). > > That would be dpkg-genbuildinfo from dpkg-dev. Back when we started with > reproduce.d.n I discussed this and similar options with others and we agreed > that fakeroot is an implementation detail and not a build dependency of the > package. Also there is ongoing work to remove the fakeroot usage in the > archive completely.
If the presence of fakeroot may affect the end result, it would seem natural that it should be recorded in the buildinfo file. I could agree about the fact that it's not a build-dependency in strict sense, so maybe it's ok that it's not in the Installed-Build-Depends field of the buildinfo file, but if it's not there maybe it should be somewhere else. Even a "Fakeroot-Version:" field would be (or "would have been", depending on we look at it...) better than nothing. My feeling is that we are mixing things that should be independent and handled separately. For example, the proposed patch (which I will probably accept before the freeze of forky), says "This makes the package reproducible". That's probably not a fair way to explain the issue. Most probably the package was indeed reproducible, but the infrastructure "forgot" to record essential information to actually reproduce it. (Side note: Maybe I will just change the comment in the patch to something like "The package may now be reproduced by reproduce.debian.net"). > > > we can't use it during the rebuild > > > > Well, maybe you should use it during the rebuild even if it's not in > > the buildinfo file. It looks like this should be done in general for > > every package having a Rules-Requires-Root different than no. > > The problem is that we don't know which version of the fakeroot package was > used during the build. There where proposals to guess the likely version by > the build date or scrape it from the buildd log but it would mean more > hacks. Ok, I admit that I did not think about that. Let's assume that we can't guess the fakeroot version of a package which was already built. Could not we at least start recording the fakeroot version so that from now on packages that rightfully use it may be reproduced? That way a simple rebuild (which could be even a binNMU) would suddenly make the package reproducible again. (I fear that I know what your reply to this could be: We would be adding such field to be used by only a handful of packages, which could be switched to debputy anyway. Did I guess right? :-) > And looking at #1114644 that a bookworm fakeroot does not work on a > trixie kernel that may not even be enough... Well, as a workaround, we can agree that packages in bookworm should be built in bookworm. > > The package was built using sbuild, and sbuild installs fakeroot when > > building the package, so it could be argued that you are not really > > trying to reproduce the package correctly if you omit fakeroot. > > Note that a newer sbuild only installs fakeroot when R³: binary-targets is > set. Yes, sorry, that's what I meant: The package was built using sbuild, and sbuild installed fakeroot after detecting that it was required for the build of this specific package. > Looking at > > https://codesearch.debian.net/search?q=Rules-Requires-Root%3A+binary-targets+path%3Adebian%2Fcontrol > > There are less then 250 packages left with R³: binary-targets and up to now > I only found three where it is likely the cause of being not reproducible > (investigating right now). Around 15 do not reproduce due to other reasons, > like timestamps in manpages, and the rest reproduces just fine. Ok, that's interesting. Does this mean that getting rid of fakeroot is not really a pre-requisite for achieving reproducible-builds? If yes: What special feature does procmail have that makes its usage of fakeroot troublesome regarding reproducibility, at the same time other packages using fakeroot are reproducible? Even if the proposed patch is ok and most probably I will apply for forky, I'm really curious about this. I would feel better if I know the reasons we do thing the way we do. Thanks.
