On Tue, 2018-06-05 at 15:35:13 +0100, Sean Whitton wrote:
> On Tue, May 08 2018, Guillem Jover wrote:
> > On Sat, 2018-05-05 at 11:58:31 -0700, Sean Whitton wrote:
> >> Package: dpkg File: /usr/share/perl5/Dpkg/Source/Package/V3/Quilt.pm
> >> Version: 1.19.0.5 Severity: minor
> >
> >> Dpkg::Source::Package::V3::Quilt unconditionally tries to chmod
> >> patches without checking whether the permissions it would set are
> >> already set on the patch:
> >>
> >> chmod(0666 & ~ umask(), $patch)
> >> or syserr(g_("unable to change permission of '%s'"),
> >>$patch);
> >>
> >> In my setup I sometimes want to build source packages from trees that
> >> are not owned by the user calling dpkg-source, so the chmod call
> >> fails. It would be nice if dpkg would check whether the chmod would
> >> do anything, and not try to call it if it would not.
> >
> > The above call is part of the registering patch logic when there's an
> > untracked delta, so I'm having a bit of a hard time understanding how
> > the scenario presents itself? Also about building a source package on
> > a tree you have no write permissions on?
> >
> > I'd appreciate some more detail on how you'd want to use this or how
> > you are using it now, and exactly how it fails, etc?
>
> I have write permissions on the tree, but not ownership, so the chmod
> fails, but I do have permission to add more patches to the
> debian/patches/ dir.
>
> While building a source package clearly requires write perms, I don't
> see why it should require ownership of the files, so it would be nice if
> the code checked whether it needed to chmod before going ahead and doing
> so.
Hmm, I think this might be based on a false premise though? While your
specific package might not need ownership, I think that's not something
you can generally assert about source packages.
Say, any package that is not "3.0 (quilt)" and applies patch series
including git formatted patches with permission fixes. Or debian/rules
fixing those explicitly in case those were broken in the upstream
sources.
I guess, I can indeed check the current perms and see whether they match
the new ones and avoid the chmod calls, but then I'm not sure I can
guarantee this will not happen again, as regression testing this is
going to be interesting. And that does not control what people need/want
to do in source packages anyway. :)
Thanks,
Guillem
