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: