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

Re: Bug#52351: packaging of xawtv is bizarre!



On Thu, 9 Dec 1999, Hamish Moffatt wrote:

> The source package for xawtv is bizarre! Is there any reason the
> real upstream .tar.gz cannot be the .orig.tar.gz as Debian intends?

First off, no where is it documented(1) that orig.tar.gz is supposed to be the
same as the upstream tarball.  This has been the common definition of
'pristine' in Debian, but it is documented.

I did it this way(2) so I can have easy(very) separation(3) of patches, and
apply them in lock-step fashion.  Also, when a new upstream comes out, all my
patches are small and separate, and it is easy to see if a particular patch
has been applied upstream.  If so, I just remove it from the patches
directory, and continue on.

> The format you have used makes it impossible to make easy tweaks
> to the upstream source. I just want to experiment with it a bit.
> If I make my changes I would have to repack the source. Ugly.

On the contrary.  This system is current in use by 24(4) debian
packages, not all of which are mine.

==
dpkg-source -x foo*.dsc
cd foo-#.##/
chmod +x debian/sys-build.mk    (this isn't absolutely nescessary)
debian/sys-build.mk source.make
cd build-tree/foo-#.##/
(edit source, change lots of files)
cd ../..
debian/rules make-diff
mv debian.diff debian/patches/###_my_uber_elite_jiz_thingamabob.diff
==

The ### in the diff name is not absolutely nescessary, as it is only used to
make sure the patches apply in a particular order(I |sort internally).

Yes, I do agree that the first time you see a source package modfied this way
it is a shock.  But once you get over the learning curve, there is no going
back.  I even have a script that can take a .dsc and convert it to this split,
delayed patch handling system.

Also, the point about .orig.tar.gz != upstream .tar.gz being true will be
addressed during christmas vacation.  I have had an idea of how to make this
all work when only one upstream tarball exists, but haven't had enough time to
implement it.

----BEGIN GEEK CODE BLOCK----
Version: 3.12
GCS d- s: a-- c+++ UL++++ P+ L++++ !E W+ M o+ K- W--- !O M- !V PS--
PE++ Y+ PGP++ t* 5++ X+ tv b+ D++ G e h*! !r z?
-----END GEEK CODE BLOCK-----
----BEGIN PGP INFO----
Adam Heath <doogie@debian.org>        Finger Print | KeyID
67 01 42 93 CA 37 FB 1E    63 C9 80 1D 08 CF 84 0A | DE656B05 PGP
AD46 C888 F587 F8A3 A6DA  3261 8A2C 7DC2 8BD4 A489 | 8BD4A489 GPG
-----END PGP INFO-----

1: packaging-manual, version 3.1.1.1, section 3.
   debian-policy, version 3.1.1.1, section 2.4.

2: Actually, Branden Robinson, the XFree86 maintainer, came on irc one day 
   back in the spring, asking for help in designing a new source management
   system.  After a 2 day weekend, I had this system mostly finished, and
   after another week of tweaking, it was mostly done(the work on it didn't
   stagnant at that point, tho).

3: For X(yes, using this as an example again), there are currently 77 separate
   patch files, containing 27458 lines of diffs, and taking up 841641 bytes.
   If that were one HUGE .diff.gz, think how hard it would be to port to each
   new upstream release.  With them all separate, it makes it easy to drop a
   particular patch when it has been included upstream(or, to send a patch
   upstream).  I don't think anyone would want to handle that as one huge
   diff.

4: doogie@master $ time find /debian2/debian/dists/potato/ -name
   '*.diff.gz'|xargs -n 100 zgrep -l 'sys-build.mk'|wc
        24      24    1686

   Yes, 24 separate source packages using my system.  This does not include
   packages that contain similiar source management systems(glibc and gcc/egcs
   come to mind).


ps: note how big packages are being maintained with patches/tarballs handled
    separately.


Reply to: