On Mon, Aug 18, 2025 at 06:08:36PM +0200, Niels Thykier wrote:
> Historically, the `(fake)root` dependency was implicit and something the
> builder provided, so it is impossible for us to determine what was used as
> gain root command in theory. In practice it was `fakeroot` (sbuild,
> pbuilder, buildds) or real `root` (CI systems where the script run as root).
>
> The safer option would be for `debrebuild` to always pull in `fakeroot` when
> in doubt. I would not like it personally because I want to remove `fakeroot`
> plus the design choice for only pulling in direct declared dependencies.
Well, I see why you dislike it, as I also share your willingness to
get rid of fakeroot in the long run, but we are using debrebuild to
check reproducibility of packages *already* in the archive, where
fakeroot was still used, so I would say that dropping fakeroot now
is still premature. If there is a small change in the heuristics that
could be made so that past versions of smartlist appears as
reproducible, I think that would be the way to go for this bug.
> [...]
> For smartlist, I suspect the problem is:
>
> ```
> override_dh_auto_install:
> install -d -o ${smart} -g ${smart} -m 700 debian/tmp/var/list
> ```
>
> The `-o ${smart} -g ${smart}` can likely be removed, since `dh_fixperms`
> will reset all of those things later to `root:root` followed by the code
> running after `dh_fixperms` that will reset owner one more time. I suspect
> the `-m 700` might be redundant there, but it is less problematic once the
> `-o` disappears.
>
> The only exception is if upstream's install script checks permissions and
> starts erroring out messes with them.
>
> That being said, I do not understand this weird hybrid setup where we can do
> chown to root but we do not actually have root permissions. A true root (or
> `fakeroot`) would ignore the not being the owner and not having relevant
> permissions. A normal user would fall at the `install -o` part. I find it
> scary that we somehow managed to get/invent a new failure mode where we are
> 50% root. Therefore, I am less sure if my fix works here or it just runs
> into the "50% root" problem a few lines later now.
I agree that this hybrid setup is not very orthodox. At the time, I
never thought that we would be willing to get rid of both sudo and
fakeroot to build packages in the future.
I would be open to modify it slightly. For example, putting all
ownership and permissions changes right after dh_fixperms and removing
them elsewhere. The bad thing is that this would only solve the
problem for the next upload, but not for past versions already in the
archive.
> [...]
>
> I am less sure if `smartlist` could be converted to
> `dh-sequence-debputy-rrr` since it seems to disable `dh_md5sums` explicitly,
> which is currently not supported under `debputy` currently. I would have to
> understand the use-case and add support for it first provided the conversion
> has any interest at all.
This is because smartlist is weird in more than one way... The lists
live in /var/list (for example, /var/list/debian-devel) but /var/list is
also the directory where txt templates and procmailrc files controlling
the flow of messages are put, so those files need to be conffiles
(even if they are not in /etc) and we can't run md5sum on them.
I could probably use dh_md5sums and then modify the outcome
afterwards so that those conffiles-not-in-etc are excluded.
Jochen Sprickerhof wrote:
> I think you are jumping to conclusions too fast here. You can get the
> same failure by building smartlist as root whereas building it as root with
> fakeroot works. So smartlist detects fakeroot in some way and behaves
> differently. @Santiago could you give some insights here?
Are you really sure about that? I've just tested "dpkg-buildpackage -rsudo"
and it worked for me. Is -rsudo what you meant by "building as root"?
Thanks.
