Re: dpkg-source v2
On Mon, 2002-07-22 at 13:16, Joey Hess wrote:
> Colin Walters wrote:
> > I see your point. I think I agree. So I'll change it so it does by
> > default build a diff of the unpacked source directory; it will then be
> > dropped in debian/patches/00debian.patch.
> That's great. (Aside from the sucky name, but foo. Well, couldn't you
> use debian/patches/debian; if you're doing an alphanumeric sort that
> will come after any [0-9][0-9]\w patches maintainers create.)
Ok, debian/patches/debian.patch it is.
> Yuck. I have a few upstream debianized packages; making them native is
> not a very appealing route, and sticking with v1 will only work so long.
Well, there is of course a third option; remove the debian/ directory
manually from the upstream .orig.tar.gz. I don't like that option
though, because it sucks to have to change the .orig.tar.gz; people
verifying the md5sum will have to go to extra trouble.
> > Personally, if the package has a debian/ upstream, that probably means
> > upstream is very responsive to Debian, so making it Debian-native makes
> > sense in a way.
> Unfortunatly that might not be true at all, it may have been patched in
> by someone who was a debian fan and had cvs commits, and now the project
> is dead or dormant or just nonresponsive about the issue upstream.
Well, if debian/ isn't actively maintained in the upstream CVS or
whatever, then it should probably just be removed. It definitely
shouldn't be in the tarballs they release, at least; otherwise people
might actually attempt to use it, when they'd be better off getting a
version from ftp.debian.org/debian/pool.
When it is actively maintained, then it's more of a native package.
> Ah, but you could rename the db component to
> evolution:sqldb_version.orig.tar.gz (or some other name that makes
> sense; I don't know what the db is), and get it in a sqldb subdirectory,
> avoiding the collision.
Hmmm...that seems ugly to me; at least equivalently ugly to having
single and multiple upstream source packages unpack so differently. I
guess this is really a nontechnical cosmetic issue, in the end.
> What if it used a rule like this:
> For each tarball:
> If there is a colon in the tarball's filename, unpack that tarball
> in package-version/<bit-after-colon>.
> Else if there is no colon, (and there must only be one tarball with no
> colon), unpack it in package-version/.
Ok, I agree. I think I know this is the correct answer because it makes
the code simpler.
> This also has the advantage of letting the desperate work around packages that
> have a debian directory upstream.
Eeek. I guess I can just look the other way and pretend you're not
doing it :)
To UNSUBSCRIBE, email to email@example.com
with a subject of "unsubscribe". Trouble? Contact firstname.lastname@example.org