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

Re: dpkg-source v2

On Mon, 2002-07-22 at 00:50, Joey Hess wrote:
> Colin Walters wrote:
> > ** Changes to the upstream source will NOT be preserved when building
> > a non-native version 2 archive.  You must generate a patch, and put it
> > in debian/patches.  See below.


> I would even say that it should default to making a automatic diff for
> packages that have explicit patches too; so if you download a source for
> a quick NMU, you don't have to worry about messing with adding a new
> patch.

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.

> I think they're going to make life much harder for those of us who want
> to check the resulting tree into cvs. I don't want to have to rename an
> entire directory in cvs when a new upstream comes out. It would be much
> better if the source format let us specify what directory each source
> tarball extracted to, so the db part could go right in db/ and the
> evolution part right into evolution/. You seem to have the needed
> information already.

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.

(By the way, thanks for giving this feedback; this is exactly the kind
of thing I need to know.)

> There's also a bit of an inconsistency between the directory format for
> single-source packages and multi-source packages; when adding a second
> source to a single source package the first source would all have to be
> moved into packagename-version/firstsource-version/; which again will
> truely suck in cvs.

Yeah...I think adding a second source would be a rare occurrence
though.  I didn't really want to make the unpacking directory confusing
for packages with just a single upstream (i.e. the vast majority).

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

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.

> 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".

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.

> 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"?

> Of course this stuff all gets sticky pretty fast with order-dependant patches
> and patch dependancies, and I doubt I'd ever really use this. 

Yes; but I have to do that work anyways, because I do plan to support
reversing and applying individual patches, along with the patches that
depend on it. You can already reverse all the patches:

dpkg-source -p --reverse --apply-all

> But the same
> facility could be used like so, assuming 'debianization' is the standard
> debianization diff for packages that do not separate up their patches:
> dpkg-source -p create debianization
> So that would take the original sources, unpack them, apply any patches
> from my current source tree except the debianization patch, and diff the
> result against my current source tree. If this were then run
> automatically when dpkg-source builds a package, it would solve my
> concern at the top of this message.

I think that makes sense.

To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Reply to: