Re: Intent to commit craziness - source package unpacking
Russ Allbery writes ("Re: Intent to commit craziness - source package
unpacking"):
> Ian Jackson writes:
> > I'm not sure of the logic behind that. I don't think dgit helps much
> > with the kind of tasks that pristine-tar helps with.
>
> The main benefit of pristine-tar is that you can clone the development
> repository on any random host and do package development, build local
> packages for testing, and do a package upload without having to locate any
> additional pieces. I haven't been following dgit development closely, but
> it did sound like you were addressing the same use case.
dgit will fetch the orig tarball for you. So you don't have to
"locate" the pieces, but you do have to pay the download cost.
> If sbuild is now at the point where you can just apt-get install sbuild,
> run a single setup command, and be ready to build packages (which is where
> cowbuilder is right now), I personally would be happy to use something
> that's a bit closer to what the buildds are doing.
There is sbuild-setupchroot or something. I do find that I don't want
it because I like fiddling with the config, so I just use lower level
commands myself.
> However, cowbuilder does just work, in my experience, and it's nice to not
> have to change.
Of course.
I'm sorry I stepped into the argument about which chroot build tool is
best :-).
Ian.
--
Ian Jackson These 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: Intent to commit craziness - source package unpacking
Guido Günther writes ("Re: Intent to commit craziness - source package
unpacking"):
> On Mon, Oct 03, 2016 at 04:15:08PM +0100, Ian Jackson wrote:
> [..snip..]
> > Recommends: pristine-tar (>= 0.5)
...> >
> > pristine-tar has been declared unmaintainable by its original
> > author and abandoned.
...
> > Certainly dgit users do not need pristine-tar. But our dependency
> > system does not allow us to honour only direct Recommends and not
> > transitive ones.
>
> Looking at git.debian.org I found plenty of users. I did an archive
> import of sid during Debconf and was only ran into 20 pristine-tar
> failures (bugs yet to be filed).
Interesting.
> From the discussions at DC16 we're on our way to make this a hard
> dependency:
>
> http://lists.sigxcpu.org/pipermail/git-buildpackage/2016-July/000143.html
>
> The only thing I can think of (since we will keep support for not using
> pristine-tar nevertheless) is using:
>
> Recommends: pristine-tar | dgit
I'm not sure of the logic behind that. I don't think dgit helps much
with the kind of tasks that pristine-tar helps with.
> > Recommends: cowbuilder<= jessie
> > Recommends: cowbuilder | pbuilder | sbuild<= sid
...
> gbp buildpackage has integration with pbuilder/cowbuilder (via
> git-builder) and I know people are using it since its better integrated
> into gbp since you don't need additional and it's documented in the
> manual. The sbuild dependency is there to have people not pull in
> cowbuilder/pbuilder so they can use --git-builder=sbuild.
Ah.
> Not sure what can be done here.
It sounds like it should be left as-is, TBH.
> > Depends: devscripts
> >
> > devscripts is very full of commands with poor namespacing. It
> > also has an enormous dependency chain.
> >
> > Unfortunately dgit has a dependency on devscripts too. Maybe we
> > should work to take the pieces of devscripts that we really need
> > and put them in something else, or something.
>
> We're mostly using dch with "gbp dch" and I would also be happy to have
> the dependency chain shortened.
If it were my package, and that was all I depended on devscripts for,
I would drop it entirely. I think it's fair to expect someone who
uses `gbp dch' to install the package containing dch. But this is a
matter of taste.
dgit has a much harder dependency because dgit push uses dput.
Ian.
--
Ian Jackson These 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: Intent to commit craziness - source package unpacking
Hi Ian, On Mon, Oct 03, 2016 at 04:15:08PM +0100, Ian Jackson wrote: [..snip..] > Because I'm a pernickety type of person I reviewed the dependencies of > git-buildpackage. I have some qualms about the following > dependencies: > > Recommends: pristine-tar (>= 0.5) > > pristine-tar has been declared unmaintainable by its original > author and abandoned. > > IDK know what proportion of actual git trees that gbp users will > encounter would break without pristine-tar. Perhaps this > dependency can be demoted to Suggests, but I don't really know. > > Certainly dgit users do not need pristine-tar. But our dependency > system does not allow us to honour only direct Recommends and not > transitive ones. Looking at git.debian.org I found plenty of users. I did an archive import of sid during Debconf and was only ran into 20 pristine-tar failures (bugs yet to be filed). >From the discussions at DC16 we're on our way to make this a hard dependency: http://lists.sigxcpu.org/pipermail/git-buildpackage/2016-July/000143.html The only thing I can think of (since we will keep support for not using pristine-tar nevertheless) is using: Recommends: pristine-tar | dgit > Recommends: cowbuilder<= jessie > Recommends: cowbuilder | pbuilder | sbuild<= sid > > Many users of dgit will never want to build a package for upload. > This is probably true of gbp users too. I'm not sure why it's > valuable to have this as a Recommends dependency for gbp. > > I think more people now are using sbuild. I'm not sure that > pulling in cowbuilder on systems where the user has not yet > installed such a tool is right. gbp buildpackage has integration with pbuilder/cowbuilder (via git-builder) and I know people are using it since its better integrated into gbp since you don't need additional and it's documented in the manual. The sbuild dependency is there to have people not pull in cowbuilder/pbuilder so they can use --git-builder=sbuild. Not sure what can be done here. > Depends: devscripts > > devscripts is very full of commands with poor namespacing. It > also has an enormous dependency chain. > > Unfortunately dgit has a dependency on devscripts too. Maybe we > should work to take the pieces of devscripts that we really need > and put them in something else, or something. We're mostly using dch with "gbp dch" and I would also be happy to have the dependency chain shortened. > Overall I don't think these are an impediment. But since I had done > the review, I thought I'd share my thoughts. Cheers, -- Guido ___ vcs-pkg-discuss mailing list vcs-pkg-discuss@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/vcs-pkg-discuss
