Re: Intent to commit craziness - source package unpacking
On Mon, Oct 03, 2016 at 04:15:08PM +0100, Ian Jackson wrote:
> Because I'm a pernickety type of person I reviewed the dependencies of
> git-buildpackage. I have some qualms about the following
> 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
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.