Re: dpkg-source v2
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.)
> I guess there's no particular major reason not to name the unpacked
> upstream source directories without the version; I just thought it
> looked nicer with. If it would be painful for cvs-buildpackage users,
> I'll change it.
It might be possible to deal with the versioned directories with
modules, but that's many more cvs modules than I feel like trying to
maintain.
> > Another concern: How will this new source format deal with packages that
> > already have a debian/ directory upstream? Seems that with debian/ in
> > both the upstream tarball and in the .debian.tar.bz2, things could get
> > rather nasty pretty quick -- nastier than maintaining such packages
> > already is, even.
>
> Right now it bombs out with an error. I personally think released
> upstream tarballs should not a debian/ directory. This doesn't mean it
> can't be in the upstream CVS or something, but it should not be in the
> foo-1.0.tar.gz they release.
>
> I'm aware this was the subject of "active discussion" a while ago, and I
> know people disagree with me, so if one (against all common sense :) )
> does have debian/ in the upstream tarball, then one can make the package
> debian-native, or just stick with version 1 archive. I don't really
> have any other solutions.
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.
> 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.
> > Another approach might be to designate one source tarball as the primary
> > source -- this goes into packagename-version/ . Secondary source
> > tarballs, which includes any other upstream sources and maybe the
> > debian.tar.gz would go into subdirectories. Giving the maintainer
> > control of exactly what the names of those subdirectories are, if
> > feasable, would be really neat.
>
> Mmm...it would be neat. To do this though, the maintainer would really
> have to have control, because namespace clashes are quite likely; e.g.
> if the primary source has a subdirectory of the same name as one of the
> secondary sources. For example, it is certainly possible for the
> evolution upstream to have a subdirectory "db".
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.
> The other thing is though, I don't want to make life TOO hard for those
> trying to unpack a source package manually. If we give the maintainer
> complex control over unpacking, that's another step they have to follow,
> or the later build process will fail confusingly.
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/.
Compare with the current rule:
If there is exactly one tarball (which will have no colon), unpack it
into package-version/.
Else, if more than one tarball, unpack each into
package-version/<bit-after-colon>
Finally, unpack the package_version.debian.tar.bz2 into
package-version/debian
I think my version is simpler. The .dsc for evolution would then look
like this:
98de5a37e7ff94ba30607671176e8a2c 13852125 evolution_1.0.7.orig.tar.gz
5baeb94fb934d0bf783ea42117c400be 1954117 evolution:db_3.1.17.orig.tar.gz
00fdddef14f104800edbba00e67dabf3 16806 evolution:debian_1.0.7-2.tar.bz2
This also has the advantage of letting the desperate work around packages that
have a debian directory upstream. My acpi package might look like this:
44bb987e329065b1b7ffc0cb34dab16c 34911 acpi:upstream_0.0.5.orig.tar.gz
dda6adc8a746ba9b0ac36349884a7616 2374 acpi:debian_0.0.5-4.tar.gz
So I get:
acpi-0.0.5/
debian/
upstream/
debian/
src/
(acpi is a bad example, as its author is entering new maintainer.)
> > Wouldn't it be better if this generated a patch against the upstream source
> > tree with any other existant patches applied?
>
> That's exactly what happens (or at least what the implementation intends
> to do :) ). This is the same way dbs works.
>
> > Of course if I later on add more patches to that package and have to revisit
> > LFS support, it would also be nice if I could update that LFS patch by
> > telling dpkg-source to generate a diff between the current tree, and the
> > old patched tree minus my old lfs patch. Perhaps something like this:
>
> Couldn't you just do "rm debian/patches/lfs.patch" before running
> "dpkg-source -p --create"?
Yes I think you're right.
--
see shy jo
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: