Re: dpkg-source v2
Colin Walters wrote:
> Well, I take that back. It definitely makes the unpacking code simpler,
> but the packing code becomes more complicated. Currently, the hack for
> multiple upstream sources I use is to add a "Source-Style: multi" entry
> to the debian/control file. When that entry is present, dpkg-source v2
> looks at the subdirectories in the unpacked directory, and figures out
> what each of the upstream sources and their versions are from that.
Couldn't it instead glob over ../<source-package>_*.<version>.tar.* and
work out the info from there? Perhaps this fails if you have multiple
souces each with different versions in the tarball names, but I hadn't
thought it made sense to do that.
> Actually, a third solution occurs to me; we create another file,
> source-control.xml, which is separate from debian/control, and would
> allow you to customize all these things. Yeah. Now that I think about
> it, this solution is probably the best.
It'd better than the other two ideas. I was hoping to avoid having to
write xml in my day-to-day packaging though. :-P
It seems to me that you should be able to package a package up knowing
only the same set of information you'd use to unpack a package. I've not
proven this, it's just instinct. If true though there'd be a certian
elegance in storing the info used in packing in the same format as the
info used in unpacking (the dsc). Just a thought.
Maintainer: Joey Hess <firstname.lastname@example.org>
Build-Depends: debhelper (>= 4), automake, autoconf, help2man, dpkg-dev (>= 1.9.0)
Architecture: i386 ia64
FWIW that control file builds ok with current tools, just a little
griping about the new field.
Now that I think about it though, I don't want to be stuck fiddling more
versions in debian/control or anywhere else if it can be avoided. I
really hope my first idea up at the top is valid.
see shy jo
To UNSUBSCRIBE, email to email@example.com
with a subject of "unsubscribe". Trouble? Contact firstname.lastname@example.org