Re: dpkg-source v2
- To: email@example.com
- Subject: Re: dpkg-source v2
- From: Anthony Towns <firstname.lastname@example.org>
- Date: Sun, 6 Oct 2002 22:45:42 +1000
- Message-id: <[🔎] 20021006124541.GA26668@azure.humbug.org.au>
- Mail-followup-to: email@example.com
- In-reply-to: <1027450095.29878.50.camel@space-ghost>
- References: <20020722045020.GA1597@silk.kitenet.net> <1027330345.21153.30.camel@space-ghost> <20020722171632.GD1671@silk.kitenet.net> <1027361617.30604.25.camel@space-ghost> <1027391232.7232.80.camel@space-ghost> <20020723032943.GA12079@kitenet.net> <1027401139.8301.37.camel@space-ghost> <20020723161432.GE17369@silk.kitenet.net> <1027450095.29878.50.camel@space-ghost>
On Tue, Jul 23, 2002 at 02:48:14PM -0400, Colin Walters wrote:
Tralala. http://people.debian.org/~walters/debian/experimental doesn't seem
to have anything new yet, so continuing where we left off...
> 1) Refactor the current implementation so that the filenames for
> multi-source packages are as aj suggested; this avoids having to
> hardcode a version anywhwere.
This refactoring was to have sources look like:
This was probably a bad idea though -- since glibc and linuxthreads
probably don't rev at the same time, it's a waste of space, and probably
generally confusing. So while it'd be nice to be able to just do
to get the source for an app, it's probably not worth the effort. That's
why we've got the .dsc anyway.
> 2) Add a file debian/source-control which specifies what sub-sources
> exist, and how they should be unpacked.
So maybe a better idea is to just let you have different upstream sources
with varying names and versions, and to expect you to tell dpkg-source etc
when that's the case, and give it the details it needs. The place we do
that at the moment is the changelog, which has the source package name and
the version number. We could extend that, perhaps something like:
] glibc (2.2.5-14.3; linuxthreads 1.2.3) unstable; urgency=low
] * NMU
] * debian/patches/glibc22-mips-mcontext.dpatch: delete.
] -- Ryan Murray <firstname.lastname@example.org> Sun, 15 Sep 2002 14:21:21 -0700
which then might as well be:
> This information would then be
> encoded into the .dsc somehow.
I'd be half inclined to say:
<src>_<upstream>.orig.tar.gz -> unpacked into <src>-<upstream>/
<foo>_<ver>.orig.tar.gz -> unpacked into <src>-<upstream>/<foo>
<src>_<upstream>-<revision>.diff.gz -> patched
...for each file listed in the .dsc. If you were /really/ desperate,
you could then have <src>_<upstream>.orig.tar.gz *completely missing*
from the .dsc, so you'd get everything created in its own subdirectory.
This could be determined be the "packing" scripts by the lack of a
../<src>_<upstream>.orig.* file and possibly some other cues -- like
the changelog modifications above (to avoid it creating a Debian native
That might look something like:
] libc (2.2.5-14.3; glibc 2.2.5, linuxthreads 1.2.3) unstable; urgency=low
Anthony Towns <email@example.com> <http://azure.humbug.org.au/~aj/>
I don't speak for anyone save myself. GPG signed mail preferred.
``If you don't do it now, you'll be one year older when you do.''