Re: sbuild vs pbuilder (and dgit)
Hi!
On Mon, 2016-11-28 at 17:39:46 +0000, Ian Jackson wrote:
> Scott Leggett writes ("Difference in behaviour between pbuilder and sbuild"):
> > I've recently tried using sbuild rather than pbuilder (inspired by a
> > blog post[0]),
> >
> > [0] https://people.debian.org/~stapelberg/2016/11/25/build-tools.html
[ BTW, also extremely biased here, but I think the odd language there
is obviously python. ;) As you need shell for Makefiles anyway, and
dpkg-deb and similar are in C too. ]
> I have never really understood the point of debuild.
It used to have many features not present in dpkg-buildpackage itself.
This has changed in recent times, and they are more or less on par,
with debuild still having some advantages or nicer defaults that would
be difficult to set in dpkg-buildpackage.
I might be forgetting something but I think the remaining items are:
- Generates a build log.
- Runs lintian by default (dpkg-buildpackage can now be configured
to do so, but it needs user action).
- Environment cleansing.
- Checks the source tree directory name for sanity.
- Can run multiple targets from a single command.
- Can use debsign/debrsign.
Most of those differences should disappear in the future, though.
On Mon, 2016-11-28 at 17:49:53 +0000, Ian Jackson wrote:
> There is a historical anomaly about .gitignore in source packages.[1]
> [1] Several tools like to drop .gitignore from source packages,
> especially if they have been created by the Debian maintainer.
>
> However IMO you should ship the .gitignore in the source package.
>
> Given the abysmal mess of git workflows and tools and competing repos
> and what have you in Debian, there are several ways your source
> package might be converted back into a git tree. Someone who does
> that wants your .gitignore.
>
> Unfortunately someone somewhere decided that .gitignore was a `VCS
> file' which ought not normally to be included in `3.0 (quilt)' source
> packages. In particular, often nothig generates patches for upstream
> .gitignore files.
Got curious whether I was the guilty one, and in a way I was! :)
I merged the patch in commit 9ddc4887306f98c4562294fb2373a2ed7d87ae67
to the ignore list (which was not used by default back then) following
the precedent for other *ignore files, and then that list got enabled
by default for 3.0 formats.
I still think it makes some sense though, because this is for tarballs
that are the distribution artifacts. And if people are going to commit
the "mortal sin!" of importing those tarballs with all their autogenerated
cruft into a VCS, to be able to work there, they probably do not want
to ignore those same files that have been committed. This is also an
upstream common practice (not a justification for being good or not),
and for example most automake-based projects do not distribute .gitignore
files (and several of the few in codesearch.d.n that refer to them do so
for exclusion purposes). Including them would also not catter for cases
were upstream is stored in say bazaar or another VCS (although given the
current standing of git vs the rest, this is probably a non-issue at
this point in time).
I acknowledge that if you are in the business of source storage
conversion and similar, not having the .gitignore files might be
annoying, and having them always makes it possible to not import
them if your workflow would suffer from that. But then maybe we should
ask ourselves why are we in that case importing from the .dsc instead
of taking the upstream VCS as the baseline to be overlaid on?
In any case I'll note this down as one of the grievances with format
3.0 to take into account for future formats or revisions. Thanks!
Regards,
Guillem
Reply to: