[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: First steps towards source-only uploads

On Wed, 2014-08-13 at 12:24:49 -0700, Josh Triplett wrote:
> Guillem Jover wrote:
> >   # Full build, but filter the generated .changes file to only inlcude
> >   # source and possibly arch-indep binaries, will not fail if the
> >   # latter are missing.
> >   $ dpkg-buildpackage --changes-option=-g
> > 
> > The advantage of the second is that the package is fully built so that
> > the maintainer can test that it builds and can install and test the
> > resulting packages. Unfortunately as arch-specific packages are filtered
> > out from the .changes file, lintian will not be able to find them. So you
> > migth want to do a normal build followed by one with either -S or -g.
> I tend to use "debuild" from devscripts, primarily because it
> automatically runs lintian.  If dpkg-buildpackage gained native support
> for invoking lintian, it could do so on the unfiltered changes file, and
> then emit the filtered changes file.  Would you consider including
> support for that in dpkg-buildpackage?

dpkg-buildpackage does support running a checker like lintian since
1.17.6 (see --check-command and DEB_CHECK_COMMAND in the man page).
Doing what you request would require running dpkg-genchanges twice,
but only sometimes, I'm not sure I like how that would smell as an
interface, but I'll ponder about it (maybe just adding an option to
request the filtering, so that the build type option is passed to
dpkg-genchanges for the final .changes file, but otherwise
dpkg-buildpackage performs a normal full build, hmmm).

What comes to mind though, although slightly cumbersome, is that right
now there's also this other option, which should cover all requirements
(except being succint :):

  $ export DEB_CHECK_COMMAND=lintian

  $ dpkg-buildpackage -us -uc
  $ dpkg-genchanges -g >../pkgname_version_src+all.changes
  $ debsign ../pkgname_version_src+all.changes

(dpkg-genchanges really needs a -O[filename] option, which I'll be
implementing soon, and signing should eventually be disabled by
default anyway as discussed some time ago here.)


Reply to: