Re: dpkg-source v2
On Mon, 2002-10-07 at 00:18, Anthony Towns wrote:
> First, is that maybe it's worth removing some of the special cases. It'd
> seem relatively straight forward to have:
OK, I think your examples there make sense.
> Obviously that'd require special casing to cope with the v1 format. (I'm
> sorry, I've forgotten which way we were going with our examples. debian_*
> and bar_* as appropriate, of course)
Well, the v1 and v2 formats is currently implemented as separate
subclasses of DebianSourceArchive, so it's not a big deal to have them
differ in some respects.
> Second, is that I'm inclined to think patches should be treated as a little
> more first class, than having them secreted somewhere under debian/. The
> theory being that you go "dpkg-source -x *.dsc" and end up with the complete,
> patched source that you can then modify or grep or do whatever as appropriate,
> without getting false positives thanks to the silly diff's lying about and
Hmmm...I don't understand this at all. dpkg-source -x will by default
apply patches; that's one of the whole points of this endeavour :)
What do you mean by false positives? Like grepping for a function that
was patched would also show up something in debian/patches? That
doesn't seem like a big deal to me.
> Packages with no upstream modifications:
Hmmm. Again, I don't see what's wrong with having separate upstream
modification patches in the debian tarball.
> Packages with one patch, including the debian/ stuff:
So, doing this you would lose the ability to add binary files like .pngs
to the package, which was another goal for dpkg-source v2. Also, you'd
have to presumably have some way to tell dpkg-source -b to create a
.diff.gz instead of a .debian.tar.bz2, which is just more complexity,
for very little if any gain.
> Packages with many patches:
And same here.
> Keeping the .diff.gz around as well makes your dpkg-source-v1 special
> casing limited to have a source consisting of just a single tarball be
> called ".tar.gz" instead of ".orig.tar.gz", which would be fairly easy to
> manage too, while also helping make the archive look a lot more sensible
> without causing any new problems.
I think it is actually better for the different source formats to have
somewhat different filenames; it makes it easier to visually pick out
which files are which in say an apache directory listing.
Implementation complexity is not a problem (since the "special casing"
you mention is already implemented via subclass inheritance).