On Fri, Nov 04, 2005 at 10:22:09PM +0800, Zak B. Elep wrote: > On 11/4/05, Andrew Suffield <[EMAIL PROTECTED]> wrote: > > Which is exactly what you're supposed to be doing. Letting > > arch-buildpackage build one only makes sense when upstream uses arch, > > in which case you want to keep the control files. The whole point of > > this feature originally was to build tla itself directly from the > > upstream archive. > > I see. However, this assumes that the builder *has* a .tar.gz already > at hand;
Yes, it is assumed that the user is a Debian package maintainer, in which case they're going to be providing the upstream tarball. > had that been not the case (or, instead of a .tar.gz, he has > a .zip, or a .tar.bz2) the builder would soon see lintian errors about > the generated .tar.gz having arch directories, Those are bogus warnings anyway. > not to mention it being > a native package when it not intended to be so. The file builds as a .orig.tar.gz, it won't build a tarball at all when running with --native - that's what dpkg-source is for. > While I do see some convenience letting these arch dirs remain, I > still feel that it would be equally convenient to be able to rebuild > the source package from <package>/upstream, excluding the arch > inventories and effectively rebuilding a clean source, as the builder > can get that just as easily as the devo+debian tree. And you could carry on and say it's convinient to be able to build with arbitrary mangling of the source tree, but this all seems quite outside the scope of arch-buildpackage. It's only for preparing uploads to Debian, and functionally equivalent things. -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | `. `' | `- -><- |
signature.asc
Description: Digital signature
