On Mon, Mar 09, 2009 at 02:47:28PM +0100, Goswin von Brederlow wrote: > Raphael Hertzog <hert...@debian.org> writes: > > > On Mon, 09 Mar 2009, James Westby wrote: > >> On Sun, 2009-03-08 at 17:11 +0100, Raphael Hertzog wrote: > >> > There's nothing to specify here, dpkg-source uses all additional tarballs > >> > that match the regexp (exactly like it identifies the .orig tarball > >> > currently). > >> > >> bzr-builddeb will endeavour to provide the ".orig.tar.gz" for a format 1 > >> package, so that you can construct a source package from a bzr branch. > >> > >> This will be essentially impossible for 3.0 (quilt) packages that > >> use multiple tarballs, as there is no information in the unpacked > >> source package that tells you which tarballs are needed. This is a > >> pretty serious problem in my eyes. > > > > I could create debian/source/orig-components at unpack time and maybe even > > have dpkg-source -b check for their existence but I'm not yet convinced > > that this problem needs to be solved at the dpkg-source level. > > > > Furthermore, creating debian/source/orig-components is interesting > > for your use case together with --skip-debianization and it's somewhat > > weird to have only that file in the debian tree in that case. > > > > What do others think ? > > I think it would be good to have this in dpkg. That way all the > different RCS build scripts can use the same file and syntax. If every > rcs-buildpackage creates their own file then migrating from e.g. svn > to git means rewriting that config.
OTOH Raphael has a point: if you don't have any debian/ in your upstream code it doesn't really make sense to have a single debian/source/orig-components stored there. That is adding debian specific data (or at least data that's only needed by debian) to the upstream data. I actually thought about storing that info in svn-properties. Hauke
signature.asc
Description: Digital signature
