Bug#1056595: dgit: must not override dpkg include lists
control: tag -1 + wontfix control: close -1 Hello, As has been explained, this bug is invalid, at least as currently titled -- it's fundamental to the design of dgit that it behaves in this way. If the discussion yields some ways in which dgit can become friendlier to users and non-users, then it might be better to file new bugs with those concrete change proposals. Julien, given that you have decided not to use dgit in the near future, it would have been more helpful to frame this bug explicitly in terms of helping people like you, who have decided that. As it stands, your submission rather like a complaint, and that is not fair or kind to those of us who work on dgit. We don't want you to feel frustrated! -- Sean Whitton signature.asc Description: PGP signature
Bug#1056595: dgit: must not override dpkg include lists
Johannes Schauer Marin Rodrigues writes ("Re: Bug#1056595: dgit: must not
override dpkg include lists"):
> this bug was triggered by julian trying to work on my package sbuild
> in ubuntu. I usually upload all my packages with "dgit --quilt=gbp
> push-source" and hence the problem julian faces was created.
I'm still not sure what the precise problem is. Is it that the .dsc
in the Debian archive contains a .gitignore ?
> I'd also have no problem with resolving this particular situation by
> adding an appropriate debian/source/options to sbuild for the next
> upload. Then the same thing would happen independent of whether the
> person building sbuild uses dgit or not.
I think probably that would help. IIRC there are some strange
interactions between dpkg command line options and d/s/options.
(I can't remember the details offhand.)
dgit does look in d/s/options but mostly to check that there's nothing
there that would make dpkg-source do something that dgit doesn't want.
Maybe some of our documentation (eg, dgit-maint-native(7)) should
recommend creating d/s/options, and maybe dgit ought to check that?
> But would that be future proof as in: will dgit maybe adjust these options in
> the future and if yes, is there something dgit could do to inform me that my
> debian/source/options might be incomplete?
dgit's default behaviour in this area hasn't changed for a very long
time. It always wants to upload precisely your git tree, and
therefore it must pass dpkg-source options that make it able to
generate such a source package.
I think the only thing that might change is that #908747 might get
fixed, but that also seems unlikely and wouldn't invalidate your
d/s/options anyway.
Ian.
--
Ian JacksonThese opinions are my own.
Pronouns: they/he. If I emailed you from @fyvzl.net or @evade.org.uk,
that is a private address which bypasses my fierce spamfilter.
Bug#1056595: dgit: must not override dpkg include lists
Hi, On Thu, 23 Nov 2023 19:52:13 +0100 Julian Andres Klode wrote: > > I consider dpkg-source's behaviour, of excluding .gitignore by default, > > to be wrong: > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=908747 > > (You may recall that report, since you commented on it.) > I see, I consider dpkg's behavior to be the correct one, and if you > want to override it, do it in debian/source/options, not by passing > arguments to dpkg. this bug was triggered by julian trying to work on my package sbuild in ubuntu. I usually upload all my packages with "dgit --quilt=gbp push-source" and hence the problem julian faces was created. I'd also have no problem with resolving this particular situation by adding an appropriate debian/source/options to sbuild for the next upload. Then the same thing would happen independent of whether the person building sbuild uses dgit or not. But would that be future proof as in: will dgit maybe adjust these options in the future and if yes, is there something dgit could do to inform me that my debian/source/options might be incomplete? What do you think? Thanks! cheers, josch signature.asc Description: signature
Bug#1056595: dgit: must not override dpkg include lists
On Thu, Nov 23, 2023 at 05:57:42PM +, Ian Jackson wrote:
> Severity: -1 normal
>
> Julian Andres Klode writes ("Bug#1056595: dgit: must not override dpkg
> include lists"):
> > dgit overrides the include lists for dpkg, causing packages to include
> > additional .gitignore and similar files which dpkg-source -b will
> > exclude.
>
> Yes.
>
> This is necessary (1) so that the git trees correspond precisely to
> the .dscs (which is the invariant of the dgit git view), and
> (2) to comply with our promise to provide people with the source code.
>
> I consider dpkg-source's behaviour, of excluding .gitignore by default,
> to be wrong:
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=908747
> (You may recall that report, since you commented on it.)
I see, I consider dpkg's behavior to be the correct one, and if you
want to override it, do it in debian/source/options, not by passing
arguments to dpkg.
>
> > This creates a significant hurdle to the NMU process and downstream
> > distribution maintainers who have to figure out how to reduce the
> > delta again, because in both cases, unrelated changes should not
> > be present in the diff between the two uploads.
>
> I'm afraid I don't understand your scenario precisely. I'm
> sympathetic to the goal of removing hurdles for NMUers and downstream
> maintainers.
>
> > Like I had to spend about 20 minutes or so today trying to figure out
> > how to actually get that sorted out for a native package (I was trying
> > -i all the time when I should have passed -I), in turn I discovered
> > some other process issues but that's beside the point :D
>
> Were you trying to use dgit to make an NMU? If so what git branch
> did you start with? What options did you give to dgit?
No, I have no intention to ever use dgit. I believe its design is
directly opposed to what I consider the right workflow.
In my case it was not actually an NMU but I was building a prepared
merge downstream in Ubuntu which removed files that were present
in the Debian upload, but it's the same issue NMUers in Debian
face.
If I start with the .dsc, have no intention of ever touching dgit,
I need to manually figure out why files go missing vs the previous
upload and how to make them not disappear.
Like for both NMUs, and downstream work, what we care about is not
"oh rebuild is cleaning out some garbage in the tarball" (normally
we are happy about that), but about maintaining the smallest possible
change to the base version.
--
debian developer - deb.li/jak | jak-linux.org - free software dev
ubuntu core developer i speak de, en
Bug#1056595: dgit: must not override dpkg include lists
Severity: -1 normal
Julian Andres Klode writes ("Bug#1056595: dgit: must not override dpkg include
lists"):
> dgit overrides the include lists for dpkg, causing packages to include
> additional .gitignore and similar files which dpkg-source -b will
> exclude.
Yes.
This is necessary (1) so that the git trees correspond precisely to
the .dscs (which is the invariant of the dgit git view), and
(2) to comply with our promise to provide people with the source code.
I consider dpkg-source's behaviour, of excluding .gitignore by default,
to be wrong:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=908747
(You may recall that report, since you commented on it.)
> This creates a significant hurdle to the NMU process and downstream
> distribution maintainers who have to figure out how to reduce the
> delta again, because in both cases, unrelated changes should not
> be present in the diff between the two uploads.
I'm afraid I don't understand your scenario precisely. I'm
sympathetic to the goal of removing hurdles for NMUers and downstream
maintainers.
> Like I had to spend about 20 minutes or so today trying to figure out
> how to actually get that sorted out for a native package (I was trying
> -i all the time when I should have passed -I), in turn I discovered
> some other process issues but that's beside the point :D
Were you trying to use dgit to make an NMU? If so what git branch
did you start with? What options did you give to dgit?
Or, are you the maintainer? In which case, I'd like to know more
about what went wrong. Did some NMUer using dgit make an upload that
is causing you trouble?
As background:
I generally recommend that someone doing an NMU which they intend to
upload with dgit, also obtain their baseline package with dgit. Eg,
see
https://manpages.debian.org/bookworm/dgit/dgit-nmu-simple.7.en.html
I recommend that users should *not* use the semi-official Debian git
sources because they're not suitable for non-Debian-experts:
https://diziet.dreamwidth.org/9556.html
Of course if - like you do - you know what you're doing, then you can
start from (eg) a salsa branch. But then I'm afraid that this problem
with .gitignore may be just another one of the strange Debian things
that you have to know.
Even so, I'm open to ideas of ways to make this wrinkle less annoying.
Ian.
--
Ian JacksonThese opinions are my own.
Pronouns: they/he. If I emailed you from @fyvzl.net or @evade.org.uk,
that is a private address which bypasses my fierce spamfilter.
Bug#1056595: dgit: must not override dpkg include lists
Package: dgit Severity: important X-Debbugs-Cc: j...@debian.org dgit overrides the include lists for dpkg, causing packages to include additional .gitignore and similar files which dpkg-source -b will exclude. This creates a significant hurdle to the NMU process and downstream distribution maintainers who have to figure out how to reduce the delta again, because in both cases, unrelated changes should not be present in the diff between the two uploads. Like I had to spend about 20 minutes or so today trying to figure out how to actually get that sorted out for a native package (I was trying -i all the time when I should have passed -I), in turn I discovered some other process issues but that's beside the point :D -- System Information: Debian Release: trixie/sid APT prefers noble APT policy: (500, 'noble'), (500, 'mantic-security') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.5.0-10-generic (SMP w/16 CPU threads; PREEMPT) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to C.UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages dgit depends on: ii apt2.7.6 ii ca-certificates20230311ubuntu1 ii coreutils 9.1-1ubuntu2 ii curl 8.4.0-2ubuntu1 ii devscripts 2.23.6build1 ii dpkg-dev 1.22.1ubuntu2 ii dput 1.1.3ubuntu3 ii git [git-core] 1:2.40.1-1ubuntu1 ii git-buildpackage 0.9.32 ii libdpkg-perl 1.22.1ubuntu2 ii libjson-perl 4.1-1 ii liblist-moreutils-perl 0.430-2 ii liblocale-gettext-perl 1.07-6 ii libtext-csv-perl 2.03-1 ii libtext-glob-perl 0.11-3 ii libtext-iconv-perl 1.7-8 pn libwww-curl-perl ii perl [libdigest-sha-perl] 5.36.0-9ubuntu1 Versions of packages dgit recommends: ii distro-info-data 0.59 ii liburi-perl 5.21-1 ii openssh-client [ssh-client] 1:9.4p1-1ubuntu1 Versions of packages dgit suggests: ii cowbuilder 0.89 ii pbuilder0.231build1 ii sbuild 0.85.2ubuntu1 -- debian developer - deb.li/jak | jak-linux.org - free software dev ubuntu core developer i speak de, en
