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

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.

Source: acpi
Section: utils
Priority: optional
Maintainer: Joey Hess <joeyh@debian.org>
Build-Depends: debhelper (>= 4), automake, autoconf, help2man, dpkg-dev (>= 1.9.0)
Standards-Version: 3.5.6.1
Files: 
 acpi_0.0.5.orig.tar.gz
 acpi_0.0.5_debian.tar.bz2

Package: acpi
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 debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org



Reply to: