Re: dpkg-source v2
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.
This feels like a large step backwards to me. When I produced redhat source
packages back in the day, having to do patches manually was a big time
waster. I became a lot more productive when I moved to debian's source
format. Sure, if you need separated patches, you probably have to do it
manually but someone like me who keeps track of all changes with cvs and
has no need for separated diffs should not have to do all the diffs by
hand.
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.
Of course if you don't do that, someone else will -- I know right where
I'd put the patch generating in my personal build wrapper script. But
why force everyone to reinvent the wheel when something simple will work
in 99% of packages?
There is also some value in having a consistent name for the default diff
for packages that have only one.
> When you unpack evolution, the resulting layout looks like this:
>
> walters@space-ghost> l evolution-1.0.7
> total 16
> drwxr-sr-x 5 walters src 82 2002-07-21 03:01 .
> drwxr-sr-x 3 walters src 4096 2002-07-21 03:02 ..
> lrwxr-xr-x 1 walters src 9 2002-07-21 03:01 db -> db-3.1.17
> drwxr-sr-x 50 walters src 4096 2002-07-21 03:01 db-3.1.17
> drwxr-sr-x 4 walters src 4096 2002-07-16 13:25 debian
> lrwxr-xr-x 1 walters src 15 2002-07-21 03:01 evolution -> evolution-1.0.7
> drwxr-sr-x 30 walters src 4096 2002-07-21 03:01 evolution-1.0.7
>
> The symlinks are intended to make life easier for the debian/rules
> Makefile, so it won't have to hardcode a version.
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.
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.
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.
Using a consistent directory tree no matter how many sources might be
one way out; although I can't say I'm fond of the idea of pushing every
upstream source directory down into a subdirectory in every source
package.
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.
> * Generating patches
>
> So, you've tweaked the upstream source a bit; perhaps modified some
> paths to make it FHS compliant. Now, you want your changes to be
> permanent. That's easy. Running "dpkg-source -p --create" will
> output a patch of the current unpacked source directory versus the
> Debianized upstream directory.
Wouldn't it be better if this generated a patch against the upstream source
tree with any other existant patches applied? In other words, suppose I have
6 patches already, and I am modifying my package to add, say, LFS support.
I take the existing, patched tree, make more changes to it, get LFS working;
now I want to make a debian/paches/lfs that just has the changes I made for
LFS support.
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:
dpkg-source -p --create lfs
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. 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.
--
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: