Re: Idea: sbuild/pbuilder "--dgit" option
On Wed, Jan 04, 2017 at 03:13:49PM +, Ian Jackson wrote:
> Mattia Rizzolo writes ("Re: Idea: sbuild/pbuilder "--dgit" option"):
> > Besides, another way would be to just not build the source; there is no
> > need for it, as
> > 1) the source is already built out of the chroot
> > 2) dgit is already able to merge .changes by itself if needed
> > so you could just call it with '--debbuildopts -b' (wondering whether
> > _this_ needs a shortcut) to only build the binaries, and you have no
> > issues whatsoever concerning the source. I bet this would be a good
> > solution for sbuild too.
>
> You mean, the user would run the binaries build themselves with
> pbuilder or sbuild or whatever, and then `dgit push' would build the
> source, fold it into the .changes file with the binaries, and upload ?
not necessarily; dgit builds the source, then call
pbuilder/sbuild/whatever to build only the binaries starting from that
source it just built, then merge the .changes.
> I think this is an unwise workflow. It would make it far too easy to
> accidentally (due to human error, or perhaps bugs) build binaries from
> one set of sources, but upload them together with a different set of
> sources.
But yes, it's kinda brittle indeed.
> Where a binaryful upload is being prepared, the same invocation (by
> the human user) of the same tool should generate both the source .dsc
> and the binaries.
>
> Currently with dgit that build rune often has to be `dgit foo-build'.
> I would like more people to be able to say `foo-build': in practice,
> usually this means `foo-build --dgit'.
>
> This would be better because the user is already used to foo-build,
> and because it removes a layer from the wobbly tower of nested build
> wrappers.
Ok, I'm sold on this point (especially after today I played a little
more with dgit).
> > > What I was suggesting was that users should, as an alternative, be
> > > able to do the build themselves rather than via dgit, and still get
> > > the .gitignore included.
> >
> > Is such a method (being able to call directly the builder without going
> > through the dgit "wrapper") already supported by the other supported
> > "backends" of dgit?
>
> That paragraph makes me think you have a wrong mental model. I'm not
> sure what you mean by `backends'.
backend as in "what actually builds the package", be it pure
dpkg-buildpackage (`dgit build`), sbuild (`dgit sbuild`), etc.
Probably not the greatest of the words to describe it indeed.
> Running the (source and binary) build by hand, before running dgit
> push, already works some of the time, depending on circumstances. The
> .gitignore problem (which is the main reason why using existing build
> runes sometimes don't work) only turns up if the package contains
> changes to .gitignore.
Ack.
(this is the reply I was looking after with my question)
> If you mean "do other build tools like sbuild already have this --dgit
> option" then the answer is "no". Getting a coordinated opinion from
> build tool maintainers is what this thread is about :-).
;)
Anyway, I'm still not convinced such --dgit flag to pbuilder/sbuild
is so needed, but yes, I can see it's usefulness.
For pbuilder, feel free to send actionable requests (e.g. a bug with
'please add --dgit option that does xyz as an alias for --foo') - as I
already stated in the past.
--
regards,
Mattia Rizzolo
GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`.
more about me: https://mapreri.org : :' :
Launchpad user: https://launchpad.net/~mapreri `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia `-
signature.asc
Description: PGP signature
___
vcs-pkg-discuss mailing list
vcs-pkg-discuss@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/vcs-pkg-discuss
Re: Idea: sbuild/pbuilder "--dgit" option
Mattia Rizzolo writes ("Re: Idea: sbuild/pbuilder "--dgit" option"):
> Besides, another way would be to just not build the source; there is no
> need for it, as
> 1) the source is already built out of the chroot
> 2) dgit is already able to merge .changes by itself if needed
> so you could just call it with '--debbuildopts -b' (wondering whether
> _this_ needs a shortcut) to only build the binaries, and you have no
> issues whatsoever concerning the source. I bet this would be a good
> solution for sbuild too.
You mean, the user would run the binaries build themselves with
pbuilder or sbuild or whatever, and then `dgit push' would build the
source, fold it into the .changes file with the binaries, and upload ?
I think this is an unwise workflow. It would make it far too easy to
accidentally (due to human error, or perhaps bugs) build binaries from
one set of sources, but upload them together with a different set of
sources.
Where a binaryful upload is being prepared, the same invocation (by
the human user) of the same tool should generate both the source .dsc
and the binaries.
Currently with dgit that build rune often has to be `dgit foo-build'.
I would like more people to be able to say `foo-build': in practice,
usually this means `foo-build --dgit'.
This would be better because the user is already used to foo-build,
and because it removes a layer from the wobbly tower of nested build
wrappers.
> No, pbuilder doesn't use debuild (and why would it…), it calls
> `dpkg-buildpackage`. I know the name of the option '--debbuildopts' is
> a tad misleading, but such is life and I can't really change it now...
Oh...
> > What I was suggesting was that users should, as an alternative, be
> > able to do the build themselves rather than via dgit, and still get
> > the .gitignore included.
>
> Is such a method (being able to call directly the builder without going
> through the dgit "wrapper") already supported by the other supported
> "backends" of dgit?
That paragraph makes me think you have a wrong mental model. I'm not
sure what you mean by `backends'.
Running the (source and binary) build by hand, before running dgit
push, already works some of the time, depending on circumstances. The
.gitignore problem (which is the main reason why using existing build
runes sometimes don't work) only turns up if the package contains
changes to .gitignore.
If you mean "do other build tools like sbuild already have this --dgit
option" then the answer is "no". Getting a coordinated opinion from
build tool maintainers is what this thread is about :-).
Thanks,
Ian.
--
Ian JacksonThese opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
___
vcs-pkg-discuss mailing list
vcs-pkg-discuss@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/vcs-pkg-discuss
Re: Idea: sbuild/pbuilder "--dgit" option
Hello,
On Sun, Jan 01, 2017 at 09:29:17PM +, Ian Jackson wrote:
> Bernhard R. Link writes ("Re: Idea: sbuild/pbuilder "--dgit" option"):
> > The effect it has (and what I understand the thing you want), is that it
> > will make a build *fail* if there is a .git-ignore file that has a
> > different content than the .orig.tar.* (or is not included in the form
> > of a debian/patches/ file). Because when it is no longer an ignored
> > derivation between unpacked source and current clean working directory,
> > it is by definition an fatal error. (Unless one was to reintroduce the
> > annoying, error-hiding, error-introducing 'generate new patches at build'
> > time behaviour).
>
> This is a problem in some situations, indeed. The problem case is
> when: the source format is `3.0 (quilt)'; without
> `single-debian-patch'; and the build is being done by a maintainer;
> and the maintainer wants to build from their master branch.
>
> But I think the proposed --dgit option to a build tool can still be
> useful in some situations. For example, with other source formats, or
> with single-debian-patch (where I think the patch is autoregenerated
> as needed); or if the build is being done by a non-maintainer user
> from the dgit history view; or the maintainer is willing to invoke
> dgit to obtain the dgit history view and build from that.
Quick note that I believe you have to add auto-commit in addition to
single-debian-patch to get this automatic behaviour.
--
Sean Whitton
signature.asc
Description: PGP signature
___
vcs-pkg-discuss mailing list
vcs-pkg-discuss@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/vcs-pkg-discuss
Re: Idea: sbuild/pbuilder "--dgit" option
Bernhard R. Link writes ("Re: Idea: sbuild/pbuilder "--dgit" option"):
> The effect it has (and what I understand the thing you want), is that it
> will make a build *fail* if there is a .git-ignore file that has a
> different content than the .orig.tar.* (or is not included in the form
> of a debian/patches/ file). Because when it is no longer an ignored
> derivation between unpacked source and current clean working directory,
> it is by definition an fatal error. (Unless one was to reintroduce the
> annoying, error-hiding, error-introducing 'generate new patches at build'
> time behaviour).
This is a problem in some situations, indeed. The problem case is
when: the source format is `3.0 (quilt)'; without
`single-debian-patch'; and the build is being done by a maintainer;
and the maintainer wants to build from their master branch.
But I think the proposed --dgit option to a build tool can still be
useful in some situations. For example, with other source formats, or
with single-debian-patch (where I think the patch is autoregenerated
as needed); or if the build is being done by a non-maintainer user
from the dgit history view; or the maintainer is willing to invoke
dgit to obtain the dgit history view and build from that.
(The problem case can also be avoided if no non-debian/ .git* files
have been edited, in which case the proposed --dgit option has no
effect; or if the maintainer is happy to invoke their build tooling
via dgit, in which case dgit will pass approprate -i -I to the build
tools.)
Ian.
--
Ian JacksonThese opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
___
vcs-pkg-discuss mailing list
vcs-pkg-discuss@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/vcs-pkg-discuss
Re: Idea: sbuild/pbuilder "--dgit" option
On Sat, Dec 31, 2016 at 12:57:01AM +, Ian Jackson wrote: > Sorry, I have obviously not been clear. I was suggesting a documented > option to pbuilder which asks pbuilder to produce dgit-compatible > source packages. Oh, indeed I didn't understand that much. Well, that requires some more thoughts to me, as I'm not sold that a used need such shortcut. Besides, another way would be to just not build the source; there is no need for it, as 1) the source is already built out of the chroot 2) dgit is already able to merge .changes by itself if needed so you could just call it with '--debbuildopts -b' (wondering whether _this_ needs a shortcut) to only build the binaries, and you have no issues whatsoever concerning the source. I bet this would be a good solution for sbuild too. > Now, as you say, pbuilder invokes debuild. Maybe I should be asking > for a --dgit option to debuild. Should I CC the debuild (devscripts) > maintainers too I wonder... No, pbuilder doesn't use debuild (and why would it…), it calls `dpkg-buildpackage`. I know the name of the option '--debbuildopts' is a tad misleading, but such is life and I can't really change it now... > What I was suggesting was that users should, as an alternative, be > able to do the build themselves rather than via dgit, and still get > the .gitignore included. Is such a method (being able to call directly the builder without going through the dgit "wrapper") already supported by the other supported "backends" of dgit? -- regards, Mattia Rizzolo GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`. more about me: https://mapreri.org : :' : Launchpad user: https://launchpad.net/~mapreri `. `'` Debian QA page: https://qa.debian.org/developer.php?login=mattia `- signature.asc Description: PGP signature ___ vcs-pkg-discuss mailing list vcs-pkg-discuss@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/vcs-pkg-discuss
Re: Idea: sbuild/pbuilder "--dgit" option
* Ian Jackson [161231 01:57]: > What I was suggesting was that users should, as an alternative, be > able to do the build themselves rather than via dgit, and still get > the .gitignore included. To highlight a point that I think is quite important here: adding -i.git/ instead of the default is at least for 3.0 (quilt) packages is not about including the .gitignore. The effect it has (and what I understand the thing you want), is that it will make a build *fail* if there is a .git-ignore file that has a different content than the .orig.tar.* (or is not included in the form of a debian/patches/ file). Because when it is no longer an ignored derivation between unpacked source and current clean working directory, it is by definition an fatal error. (Unless one was to reintroduce the annoying, error-hiding, error-introducing 'generate new patches at build' time behaviour). Bernhard R. Link -- F8AC 04D5 0B9B 064B 3383 C3DA AFFC 96D1 151D FFDC ___ vcs-pkg-discuss mailing list vcs-pkg-discuss@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/vcs-pkg-discuss
Re: Idea: sbuild/pbuilder "--dgit" option
Bernhard R. Link writes ("Re: Idea: sbuild/pbuilder "--dgit" option"):
> From my point of view (and thus from a git-dpm workflow), ignoring
> .gitignore as dpkg-source does by default is the only sane thing to do.
>
> I might be wrong, but having issues with .gitignore in the generated
> source package is a dgit-only thing (and from what I understand from
> DebConf2015) also not a technical but rather an ideological dgit thing.
There are two reasons. One you might regard as ideological. One is
clearly technical. They both arise from dgit's fundamental aims.
The "ideological" reason is that the purpose of dgit is to get you a
git *view* of the actual source package in the archive (by importing
from the archive if necessary); and, conversely, to let a maintainer
publish their own git view of the source package. For the dgit branch
to be a *view* of the source package in the archive, its contents must
be identical. You may characterise it as "ideology" but I prefer to
see this as "the point of dgit".
The clearly-technical reason is that dgit provides a gateway between
git and .dsc. This gateway (with the support of other tools) is
bidirectional: .dsc's are converted to git by dgit, when the
maintainer has not pushed with dgit; conversely, a dgit-using
maintainer will inevitably be using tools which do the conversion the
other way. Obviously for this to work the conversion in each
direction has to be lossless. Dropping .gitignore is not lossless.
To make this abstract problem into a concrete example: Suppose Alice
wants to upload package P version V. She has a /.gitignore which is
not in upstream. Suppose the tools arranged for her to push a dgit
git branch for P containing the .gitignore, but upload a P_V.dsc
without the .gitignore. Suppose then an NMUer Bob, who does not use
dgit, uploads P version V+nmu1; his upload, therefore, does not
contain the /.gitignore. When Alice uses `dgit fetch', dgit will
import P_V+nmu1.dsc for her. Of course that import cannot contain
/.gitignore, so the git branch will be missing the .gitignore. It
will look, in git, as if Bob deleted the .gitignore. What has
actually happened is that Alice's tools have arranged for her to
promulgate two inconsistent views of the same version of the same
package.
> Thus I guess naming such an option --dgit would only be natural.
Does that mean that you would look favourably on a patch to add such
an option ?
> (I only wished [dpkg-source] would by default also ignore
> debian/.git* and thus include the debian/.git-dpm in the default
> ignore list).
I don't really understand git-dpm but I'm interested in ways to make
dgit play better with it. I confess that I found our last
conversation too frustrating but I'm happy to try again.
Thanks,
Ian.
--
Ian JacksonThese opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
___
vcs-pkg-discuss mailing list
vcs-pkg-discuss@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/vcs-pkg-discuss
Re: Idea: sbuild/pbuilder "--dgit" option
Mattia Rizzolo writes ("Re: Idea: sbuild/pbuilder "--dgit" option"):
> On Thu, Dec 15, 2016 at 08:25:53PM +, Ian Jackson wrote:
> > What would you think (particularly, sbuild and pbuilder folks) about a
> > supporting a --dgit option ? The effect would be to pass -i\.git/
> > -I.git to dpkg-source. (Possibly there might be other effects which
> > would be desirable, but this is the only essential one for those two
> > tools I think.)
>
> In general, I'm open to that for pbuilder (as I also expressed
> elsewhere), as long as it's not going to be documented in the "user
> manpage" and we manage changes to that interfaces only between us (i.e.,
> I don't want anybody else to start relying on the behavior of that
> flag).
Sorry, I have obviously not been clear. I was suggesting a documented
option to pbuilder which asks pbuilder to produce dgit-compatible
source packages.
Now, as you say, pbuilder invokes debuild. Maybe I should be asking
for a --dgit option to debuild. Should I CC the debuild (devscripts)
maintainers too I wonder...
> > Anyway, thanks to everyone for your opinions, whatever they may be.
>
> Here is pbuilder's maintainer view on this dpkg-source "problem":
> pbuilder never calls `dpkg-source -b` itself. The only `dpkg-source`
> invocation I found by grepping the source is
> dpkg-source -x $(basename "$PACKAGENAME")
> so, not affected by that.
> For pbuilder the only thing you can do is to pass
> --debbuildopts --source-option=-i.git/ --debbuildopts
> --source-option=-I.git
> or
> --debbuildopts "--source-option=-i.git/ --source-option=-I.git"
> whichever fits you better.
Yes, if I manage to get the pbuilder integration done soon, that is
what I will do. But I didn't need your help to figure that out :-).
What I was suggesting was that users should, as an alternative, be
able to do the build themselves rather than via dgit, and still get
the .gitignore included.
Thanks,
Ian.
--
Ian JacksonThese opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
___
vcs-pkg-discuss mailing list
vcs-pkg-discuss@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/vcs-pkg-discuss
Re: Idea: sbuild/pbuilder "--dgit" option
* Mattia Rizzolo [161229 18:56]: > On Thu, Dec 15, 2016 at 08:25:53PM +, Ian Jackson wrote: > > This is because the default ignore rules (in dpkg-source) ignore > > .gitignore, but dgit needs the source package to contain (any changes > > to) .gitignore. So dgit arranges that (if you use dgit to do the > > build-for-upload) dpkg-source gets passed -i\.git/ -I.git. > > Oh, I've never realized that... > > > What would you think (particularly, sbuild and pbuilder folks) about a > > supporting a --dgit option ? The effect would be to pass -i\.git/ > > -I.git to dpkg-source. (Possibly there might be other effects which > > would be desirable, but this is the only essential one for those two > > tools I think.) > > In general, I'm open to that for pbuilder (as I also expressed > elsewhere), as long as it's not going to be documented in the "user > manpage" and we manage changes to that interfaces only between us (i.e., > I don't want anybody else to start relying on the behavior of that > flag). > > > I'm mailing you both at once, with a big CC list, because ISTM that a > > conventional option name would be better than having each tool do its > > own thing. > > Much appreciated, thank you. > > > Anyway, thanks to everyone for your opinions, whatever they may be. > > Here is pbuilder's maintainer view on this dpkg-source "problem": > pbuilder never calls `dpkg-source -b` itself. The only `dpkg-source` > invocation I found by grepping the source is > dpkg-source -x $(basename "$PACKAGENAME") > so, not affected by that. > For pbuilder the only thing you can do is to pass > --debbuildopts --source-option=-i.git/ --debbuildopts > --source-option=-I.git > or > --debbuildopts "--source-option=-i.git/ --source-option=-I.git" > whichever fits you better. > >From my point of view (and thus from a git-dpm workflow), ignoring .gitignore as dpkg-source does by default is the only sane thing to do. (I only wished it would by default also ignore debian/.git* and thus include the debian/.git-dpm in the default ignore list). I might be wrong, but having issues with .gitignore in the generated source package is a dgit-only thing (and from what I understand from DebConf2015) also not a technical but rather an ideological dgit thing. Thus I guess naming such an option --dgit would only be natural. Bernhard R. Link -- F8AC 04D5 0B9B 064B 3383 C3DA AFFC 96D1 151D FFDC ___ vcs-pkg-discuss mailing list vcs-pkg-discuss@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/vcs-pkg-discuss
Re: Idea: sbuild/pbuilder "--dgit" option
[ avoiding to add any human to the recipients... ] Hi Ian! On Thu, Dec 15, 2016 at 08:25:53PM +, Ian Jackson wrote: > This is because the default ignore rules (in dpkg-source) ignore > .gitignore, but dgit needs the source package to contain (any changes > to) .gitignore. So dgit arranges that (if you use dgit to do the > build-for-upload) dpkg-source gets passed -i\.git/ -I.git. Oh, I've never realized that... > What would you think (particularly, sbuild and pbuilder folks) about a > supporting a --dgit option ? The effect would be to pass -i\.git/ > -I.git to dpkg-source. (Possibly there might be other effects which > would be desirable, but this is the only essential one for those two > tools I think.) In general, I'm open to that for pbuilder (as I also expressed elsewhere), as long as it's not going to be documented in the "user manpage" and we manage changes to that interfaces only between us (i.e., I don't want anybody else to start relying on the behavior of that flag). > I'm mailing you both at once, with a big CC list, because ISTM that a > conventional option name would be better than having each tool do its > own thing. Much appreciated, thank you. > Anyway, thanks to everyone for your opinions, whatever they may be. Here is pbuilder's maintainer view on this dpkg-source "problem": pbuilder never calls `dpkg-source -b` itself. The only `dpkg-source` invocation I found by grepping the source is dpkg-source -x $(basename "$PACKAGENAME") so, not affected by that. For pbuilder the only thing you can do is to pass --debbuildopts --source-option=-i.git/ --debbuildopts --source-option=-I.git or --debbuildopts "--source-option=-i.git/ --source-option=-I.git" whichever fits you better. The argument of DEBBUILDOPTS are passed to the main `dpkg-buildpackage` invocation, which is what might rebuild the source if you're doing a full build. I don't think there are no other relevant place you need to tinker with. Thank for your work in dgit, and don't hesitate to ask if you need anything else (including further input). -- regards, Mattia Rizzolo GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`. more about me: https://mapreri.org : :' : Launchpad user: https://launchpad.net/~mapreri `. `'` Debian QA page: https://qa.debian.org/developer.php?login=mattia `- signature.asc Description: PGP signature ___ vcs-pkg-discuss mailing list vcs-pkg-discuss@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/vcs-pkg-discuss
Re: Idea: sbuild/pbuilder "--dgit" option
Johannes Schauer writes ("Re: Idea: sbuild/pbuilder "--dgit" option"):
> sbuild already has an option to do just that:
> $ sbuild --dpkg-source-opts="-i\.git/ -I.git" ...
> Or by putting the following in the config file:
> $dpkg_source_opts = ["-i\\.git/", "-I.git"];
> (hope I got all the backslash escaping right there).
Right.
I wonder if a --dgit option ought to (perhaps optionally) do something
different about package clean targets. Does sbuild already have an
option to use `git clean' (and maybe `git reset') instead of the
package clean target ?
I always do all my builds-for-upload with dgit --clean=git-force (aka
dgit -wgf) now; this is pretty much a requirement when working on a
package whose maintainer is not using dgit, because package clean
targets are often troublesome.
> Unfortunately, typing this is much more involved than just putting --dgit
Precisely.
> but maybe we can do even better. I wonder:
>
> - are there other git-based workflows than dgit which need these cleaning
>options? Then the option name could be picked to be more general and not
>dgit specific
I'm not aware of any but there are so many gitish workflows in Debian
that it's hard to say for sure. I think it is quite unlikely. Here
are some arguments for thinking this is unlikely:
* Any git-based Debian workflow needs to ignore .git at least. There
is no convenient way to do exactly that: the options to do exactly
that (as seen above) are obscure, requiring a careful reading of
the docs. Conversely, there is the -i (without value) option which
is documented with vague but encouraging wording in dpkg-source(1)
and which many tool authors have discovered and used already.
* For maintainers using git-based workflows, the lack of .gitignore
(or updates to .gitignore) in source packages is invisible, because
such maintainers never work with the source packages for their own
packages. (There was not really a viable non-maintainer git
workflow, before dgit.)
* dgit is the only tool I'm aware of which actually insists, and
checks, that the git tree and the source package are equivalent
(for any value of equivalent). All the other tools that do
git<->dsc conversions are `open loop', and conversions are
typically unidirectional. So the .gitignore anomaly would not be
detected by other tools.
If you want a more generic option name `--faithful' would be a good
one, if perhaps rather tendentious :-). Personally I think `--dgit'
is a good one because if we discover that there are other things that
would work better if the builder did them differently, we can have a
single option where the user declares their workflow.
> - is there a reliable and future-proof way for sbuild/pbuilder to
>auto-detect that they are working on a dgit package? Maybe by
>examining the Vcs-Git field? Then they could pick the right
>options for dpkg-source automatically.
That's a nice idea. However, "we are using dgit" is not a property of
a package. It's a property of the user's workflow. The same package
(and perhaps even the very same git branch) can be worked on, at one
time, by a user who is not using dgit, and at another time by a user
who is.
For example, a dgit-using NMUer may work on packages with many
different (or totally absent) Vcs-Git fields. They may even do a
dgit-based NMU based on a history they found on alioth, or something.
Even if we restrict ourselves to maintainers[1], a maintainer who uses
dgit also needs to store their un-uploaded git commits somewhere. The
dgit git server does not do this (yet). So often that will be the
maintainer's own server, or a team repo on alioth.
[1] dgit is so compelling for the NMU use case (particularly, for an
NMU campaign) that the fact that need to wrap your build with dgit is
only a minor inconvenience.
> Otherwise (and also being a dgit user myself) I'm open to adding a --dgit
> option to sbuild. I'd just want to hear your ideas about the above first
> because I don't want to add an option just to deprecate it one release later.
These are all good questions. Please do ask more probing questions.
Before anyone actually implement this I would also like to hear from
at the very least the pbuilder maintainers.
Ian.
--
Ian JacksonThese opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
___
vcs-pkg-discuss mailing list
vcs-pkg-discuss@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/vcs-pkg-discuss
Re: Idea: sbuild/pbuilder "--dgit" option
Hi, Quoting Ian Jackson (2016-12-15 21:25:53) > dgit has wrappers for lots of build tools, including sbuild, > git-buildpackage, dpkg-buildpackage, and hopefully soon pbuilder > (#844125). > > This is because the default ignore rules (in dpkg-source) ignore > .gitignore, but dgit needs the source package to contain (any changes > to) .gitignore. So dgit arranges that (if you use dgit to do the > build-for-upload) dpkg-source gets passed -i\.git/ -I.git. > > Having dgit users have to use dgit as the way to invoke their builder > is undesirable. It means a bigger disruption to their workflow and > adds yet another layer to what is often quite a tall stack. > > What would you think (particularly, sbuild and pbuilder folks) about a > supporting a --dgit option ? The effect would be to pass -i\.git/ > -I.git to dpkg-source. (Possibly there might be other effects which > would be desirable, but this is the only essential one for those two > tools I think.) sbuild already has an option to do just that: $ sbuild --dpkg-source-opts="-i\.git/ -I.git" ... Or by putting the following in the config file: $dpkg_source_opts = ["-i\\.git/", "-I.git"]; (hope I got all the backslash escaping right there). Unfortunately, typing this is much more involved than just putting --dgit but maybe we can do even better. I wonder: - are there other git-based workflows than dgit which need these cleaning options? Then the option name could be picked to be more general and not dgit specific - is there a reliable and future-proof way for sbuild/pbuilder to auto-detect that they are working on a dgit package? Maybe by examining the Vcs-Git field? Then they could pick the right options for dpkg-source automatically. Otherwise (and also being a dgit user myself) I'm open to adding a --dgit option to sbuild. I'd just want to hear your ideas about the above first because I don't want to add an option just to deprecate it one release later. Thanks! cheers, josch signature.asc Description: signature ___ vcs-pkg-discuss mailing list vcs-pkg-discuss@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/vcs-pkg-discuss
