Re: dpkg-source v2
Hi aj, I'm glad you are interested in helping move dpkg-source v2
forward.
On Sun, 2002-10-06 at 08:45, Anthony Towns wrote:
> 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...
Right. Well, the current status is that Wichert expressed
dissatisfaction with some parts of my proposed design for dpkg-source
v2, and he mentioned that he had his own format design he thought would
be better. He elaborated a bit on it, I raised some issues with it, and
he promised to flesh out his format more, and post it to -devel or
something as a counter-proposal. That hasn't happened, and I personally
don't want to invest a huge amount of time in working on my format for
dpkg-source v2 (apparently) against the wishes of the dpkg maintainer.
I know Wichert is busy though, so I've tried to be patient.
Anyways, on to your suggestions:
> This refactoring was to have sources look like:
>
> glibc_2.2.5.orig.tar.gz
> glibc_2.2.5_linuxthreads.orig.tar.gz
> glibc_2.2.5-3.diff.tar.gz
> glibc_2.2.5-3.dsc
>
> 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.
Well, yes, but this is also true of the way things are currently done.
So it would not be a regression.
> 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 reason I didn't go this route is becuase it isn't very friendly to a
non-pool layout (or even just having a bunch of Debian source packages
in the same directory, not necessarily in an archive context). In your
example, if someone creates a package named "linuxthreads" then its
.orig.tar.gz will (possibly) conflict with the linuxthreads sub-source
in glibc. I kind of have the feeling this problem would bite someone
eventually, but maybe the space optimization is worth it; I don't have a
good feeling for whether that's true or not at the moment.
> ] glibc (2.2.5-14.3; linuxthreads 1.2.3) unstable; urgency=low
Yeah, that's a pretty reasonable way of specifying different versions.
> 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.
Well, other than the above filename conflict issue, this might be OK.
Actually, now that I've thought about it a bit more, it seems a little
tricky to actually achieve the space optimization you propose through
this. Say that the linuxthreads glibc plugin changes. How do you tell
dpkg-buildpackage to not include the glibc .orig.tar.gz in the upload
too? I guess maybe dpkg-genchanges could compare the new and last
versions for glibc, and not include it in the .changes if they're the
same...seems a bit kludgy to me, but I can't think of a better way.
Reply to: