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

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

> > 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
  Finally, unpack the package_version.debian.tar.bz2 into

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 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: