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

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



Reply to: